Category Archives: Editorial

What is CSS Regions, and Why Does Google Want to Kill It?

CSS Regions is a technology invented by Adobe in order to allow magazine-style layouts in web browsers. CSS Regions would solve one of the biggest problems with web layouts, which is that there’s no way to flow content from one area of a web page into another area, such as has been possible in desktop publishing for as long as desktop publishing has existed.

To understand the need for CSS Regions, take a look at any magazine — content flows around pictures, is continued on the next page, and moves to the left and right of images and pull-quotes.

Now look at a typical web site. Article content flows in one column, no matter how wide the browser window is. Separate regions of text are separate from each other. As a simple example, look at an article that spans multiple pages on a website. Those pages aren’t connected to each other. Each is an island of content — if you resize your browser window to be thinner, the same number of words still appear on page 1 and copying and dragging to highlight the content in an article doesn’t span to page 2, or even necessarily around pull quotes.

Content on web pages is fragmented into different regions in order for it to fit nicely and look good. The result is that the sort of layouts that are routine in print are impossible or highly inconvenient on the web.

CSS Regions would solve this problem by allowing web page designers to connect different parts of a web page and flow text dynamically into them. The idea is simple and intuitive.

When Adobe first proposed CSS Regions, progress was made on getting it implemented in the WebKit browser engine and even in Internet Explorer. However, Google’s decision to fork WebKit to create their own browser engine, Blink, changed everything.

Google announced earlier this year that they’re no longer pursuing support for CSS Regions, because their priority is to simplify Blink in the interest of increasing performance, particularly on mobile devices.

While performance is certainly a noble goal, I have no doubt that Google could make CSS Regions work in a performant way if they wanted to. It may be that Google has just judged CSS Regions to be too complicated (it’s really not) and is working on a better solution. Or, it may be that Google doesn’t want to have to compete with Safari and mobile Safari (which both support CSS Regions) and announcing that the most popular browser (currently Chrome) won’t support it is certainly an effective way to make sure that developers don’t start using it and get attached to how well it works in Apple’s browsers.

I certainly hope that Google changes it’s mind, or that Google and Adobe can work together to find a way to implement the functionality of CSS Regions in Chrome. In the meantime, if you’re interested in trying out CSS Regions, Adobe has released a polyfill that will enable the functionality of CSS Regions in every browser, using JavaScript.

Should you bother with semantic elements?

HTML5 has given web developers a slew of new block-level elements (or, what we would call block level elements, except now they’re called “sectioning” elements).

The HTML5 sectioning elements include main, article, section, nav, aside, header, footer, and address.

The question that more and more people are starting to ask is: does it matter whether we use semantic sectioning (aka block) elements, or is it perfectly ok to just use div as we’ve been doing for so long?

One of the main arguments for using semantic markup is that search engines take it into account and can better understand semantic HTML than generic blocks, aka ‘div’ elements.

But, we have yet to see evidence that this is true, and no one that we’ve talked to outside of the W3C seems to be convinced that there’s any real benefit to surrounding your navigation with a nav element vs. surrounding your navigation, header, footer, content area, and asides with divs.

What do you think? Do you use semantic elements consistently? Do you feel like they are actually beneficial, or would you be just as comfortable with using divs with descriptive id attributes?

Do Web Developers Need To Know HTML?

The other day, I was having a conversation with some of the best and smartest programmers and web developers I’ve ever met about my favorite topic: the future of the web. During the course of the conversation, the following statement was made:

“In the future, web developers won’t need to know HTML.”

As a person who who has been writing HTML for 20 years and who has written several books on HTML, I was more than a little interested in this statement. I remember Microsoft FrontPage, Flash, and many other tools over the years making the same promise.

But, are things different today?

The person who made this prediction cited front-end JavaScript frameworks (such as AngularJS), which can significantly increase developer productivity and produce fantastic web site user interfaces with much less code than raw HTML5, CSS3, and JavaScript.

JavaScript frameworks typically extend HTML to enable functionality. For example, take this simple AngularJS template:

<html ng-app="phonecatApp">
  <script src="bower_components/angular/angular.js"></script>
  <script src="js/controllers.js"></script>
<body ng-controller="PhoneListCtrl">

    <li ng-repeat="phone in phones">


This is HTML, with some special attributes. If you didn’t know HTML, you would need to learn it prior to learning Angular, unless you use a WYSIWYG tool. My personal experience with WYSIWYG tools, however, is that, sooner or later, you need to write code by hand. Without a knowledge of the underlying syntax of HTML and Angular, you’d be sunk.

Saying that web developers don’t need to know HTML struck me as similar to saying that English speakers don’t need to know the alphabet. I just can’t accept it. But, perhaps I’m too close to the subject.

What do you think? Will web developers of the future need to learn HTML?

Monetizing Mobile

phoneA new study by eMarketer, released this week, finds that adults in the U.S. are spending more time on their mobile devices than on desktop and laptop computers.

The same study estimates that mobile ad spending has more than doubled in 2013, while desktop ad spending has grown only 1.7%.

This should be a wake-up call. Now is the time to focus on your mobile strategy and to prepare for monetizing mobile websites in 2014, which promises even faster growth. Here are some of the things I recommend that everyone with a website, but especially everyone with a website that includes advertising, should do right now:

1. Visit your website with a smartphone. If you don’t have a smartphone handy, visit to simulate the experience of using your site on a smartphone. If your site was redesigned more than a couple years ago, chances are good that it’s not going to look good, or that it will require the user to zoom to view it (certainly a less-than-ideal user experience).

2. Read this study from IDC, which found that 79% of 18 to 44-year-olds have their phones on them or near them for all but 2 hours of their waking day. Furthermore, the same percentage (79%) say that the first thing they do when they wake up each day is to check their smartphone. Among 18-24 year-olds only, the percentage that reach for their phone before they do anything else is 89%.

3. Read this article which compares mobile ad click-through rates with desktop ads. Or, if you don’t have time to read it right now, let me give you the executive summary: mobile ads have much higher click-through rates than desktop ads.

The trend towards mobile computing is clear, and now’s the time to do the work necessary to take advantage of it!


Chris Minnick

p.s. A new session of my online class, Creating Mobile Apps with HTML5 just started! Visit our site to sign up or to view the first lesson!

Thanks for all the fish … errr…. feedback!

The book’s been out for almost two months now, and we’ve been getting some great feedback from certain of our readers. Much of this has centered around minor, nit-picky — and therefore important and noteworthy for us authors — boo-boos in either the examples as printed in the book, or in the actual HTML source code posted right here to the website (or missing in action, as has been the case for a handful of items). This kind of input always gets our attention, so Chris and I have been busy fixing the downloads and ZIP files for the book’s content, to make sure that as we find and fix mistakes, we make repairs, and immediately offer the repaired items for subsequent download to our readers.

Continue reading

Please Submit Your Errata!

Our book has now been in stores and online for one month, and we’ve gotten two reports of minor markup errors in its content so far, both from the same eagle-eyed reader. Despite our best efforts (more on that in the next paragraph) the occasional boo-boo does make it into print. When that happens we have only three burning desires:

1. To correct whatever mistakes may have occurred
2. To share that information with our readers so they don’t suffer from our mistakes
3. To make sure those mistakes get fixed before the next reprint occurs

Continue reading

On Shelves Now: Beginning HTML5 and CSS3 For Dummies!

I’m proud to announce that the latest book is in stores and online everywhere now. As the new co-author for this long-running and very popular series, I thought I’d take a moment to introduce myself and tell you what makes this book special.

My education as a web developer started prior to the first edition of HTML For Dummies, but I do vividly remember first learning HTML way back in 1993. The entire process of writing and publishing web pages was new to me (and to almost everyone) back then, and I had many questions.

I remember the frustration of following a tutorial and realizing that there was some required piece of knowledge that wasn’t being mentioned. Without that one piece of the puzzle, which I didn’t even know how to ask about, there seemed to be no hope of me making the leap from web user to web author.

Eventually, however, I would have an “ah-ha” moment that would carry me to the next stumbling block and I’d be forced to bumble around in the dark a while longer. Over time, I got really good at learning new web development skills — but it wasn’t the most efficient way to learn.

When books on HTML and web development started coming out, I gobbled them up. Before we even met, several of Ed Tittel’s books were indispensable references during the first decade of my career as a web developer.

I met Ed in 2000, when I was teaching Cold Fusion and Active Server Pages at Austin City College, and he helped me get my start as a computer book author. After writing and co-writing several books, I got burned out on writing books and took some time off…about 10 years, to be more precise.

I came out of my book-writing retirement to write WebKit For Dummies in 2011. Working with the team at Wiley was a great experience, and contributing to the For Dummies series is quite an honor for me. When Ed asked me to step in as his co-author for Beginning HTML5 and CSS3 For Dummies, I replied “YES!” within 1 minute of getting his email.

I had already been thinking about how I would approach writing a new HTML book, and I was excited to find that Ed’s vision for the book was very close to mine and both of us were very much in line with the vision of the editors at Wiley.

Our first decision was: This should be a book for beginners. We wanted to reach way back into our memories and remember every frustration we had when we were getting started, and figure out a better and more complete way to teach the basics.

Next, we decided that this should be an HTML5 book, and XHTML would be mentioned as little as possible (and preferably not at all). I felt (and still feel) very strongly about this issue. Without going into the details (I’ll save that for a later post), XHTML is the markup language that very nearly killed the web. With HTML5 now widely supported by web browsers, there’s really no reason for anyone to learn, or try to use, XHTML.

Finally, we decided that nearly all coverage of JavaScript would be cut. This was not an easy decision, since JavaScript is more important to web development today than it’s ever been (and it’s only getting more important). However, this is a beginner’s book about HTML5 and CSS3 and these are both giant topics to cover in only 400 pages. We decided in the end that we could either do a really good job of covering as much of HTML5 and CSS3 as possible, or we could do an inadequate job of covering HTML5, CSS3, and JavaScript. We picked the former.

Of all the books that I’ve worked on with other authors, this one was the smoothest and most enjoyable. It is truly a pleasure to work with Ed, and I’m confident that we put together a fantastic book.

I hope you enjoy reading and learning from Beginning HTML5 and CSS For Dummies as much as we enjoyed writing it. If you have any comments or questions, please let us know!

How to grab the 404 (Page Not Found) Error and Make It Your Own

From time to time on visiting just about any website, you’ll occasionally click on a bad link or make a typo when entering a URL, which elicits the famous 404 error. The HTTP error codes are well-defined, so you can always look this stuff up for yourself if you like. The W3C defines the HTTP status codes that drive all this stuff in RFC 2616, Section 10. Section 10 is labeled “Status Code Definitions,” where you’ll find this text for the 404 error code:

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

The key usually is that “…no other response is applicable,” simply because the server has no idea at all about what happened to the page. The generic error page that often appears when this happens can be less than informative, inspiring, or amusing. You can always test your own site by deliberately typing in a bad URL to see what happens. Thus, when I deliberately type into this very web site, here’s what shows up in response:

A generic error message, but the site's CSS ensures it's nicely packaged.

A generic error message, but the site’s CSS ensures it’s nicely packaged.

You can do better than this, if you like, but it will take some extra work. So first, let me show you some good illustrations of why you might want to do this, and then provide some pointers to potential explanations as to how you might go about making something cool, funny, or more interesting visible when your users trigger the 404 error code.

Giving You Some Good 404 Illustrations

I got the idea for this blog post while chunking through LinkedIn this morning, when I stumbled across this news item there:

Business Insider's Top Picks for All-Time Best 404 pages.

Business Insider’s Top Picks for All-Time Best 404 pages.

These are already pretty funny, with some verging on the hysterical and others on the “Huh?” side of humor. But I’ve been around the Web long enough myself to recognize this as a pretty well-established genre of “geek humor,” as a well-crafted Google search will instantly illustrate. Here’s list of links to some other yuck-worthy compilations of 404 humor:

Run the Google search yourself if this isn’t enough yucks to motivate you to check out the next step — there’s plenty, plenty more where those items came from. As for the purposes of this blog post, I’m going to assume you’re convinced, and are indeed ready to read on — so keep going, please!

How to Customize Your Own 404 Page

A wise man once told me, and I never forgot the veracity of his observation that: “The answer to any good question always beings with the same two words — namely ‘That depends…'” In the case of customizing the 404 error page, you must first and foremost understand that you’re seeking to customize the behavior of the Web server that’s serving up your pages. There’s a great tutorial on how to do this in general at, so I won’t treat you to the whole thing here, but I will share three important observations from that source:

  1. You may not have the ability to customize your 404 page, or other error pages. Your hosting provider must make this facility available to your Website, and most of the really cheapo providers don’t do this simply to save a penny here and there.
  2. You will probably need to customize your .htaccess file to, as Christopher Heng puts it (he’s the author of the afore-linked 404 tutorial I’m summarizing here) to add an error directive entry into a special file that will tell the server what to do when it encounters a specific HTML error code. For the 404 error, for example, it will typically consist of a line of text that looks something like this: ErrorDocument 404 /notfound.html. Translated into human-intelligible pseudo-code this means “Server, when you encounter a 404 HTTP error, find and display the file named notfound.html in the requester’s Web browser.” On the other hand, your site operator may have already done this as part of their basic server set-up, in which case you need to find the file referenced in that errordocument statement, and start customizing (this is described in very broad terms in step 3 that follows).
  3. Creating an error document file means building the Web page you wish your users to see if and when your hosting server encounters an HTTP 404 error. You can build all the great graphics and text that you like, but you should also consider Heng’s advice about what a good 404 page also contains, including a link to a search engine if your site has one (as we do on our 404 page displayed above) along with a link to the site’s home page, a site map, a list of frequently-mistyped URLs for your site with links to the correct pages, and other navigational aids your site might also present to users (like the navigation tabs at the top of the 404 page from our site, for example).

Indeed a good 404 page can be funny and interesting, but it should also do its most important job — that is, help users figure out where they should go next, once they reach a dead end in your pages, for whatever reason. That’s why I’m going to work with Chris Minnick, my co-author for the next edition of our book, to add a text input field to our 404 page that reads like this:

“Please take a minute and tell us what URL you entered when you wound up on this error page. You can use the Back arrow (or backspace key in most Web browsers) to return to the previous page, copy the link that caused the error, and paste it here to help us out. If we can fix it we will, and if it’s a recurring error, we can make it easier for others to get where they really want to go in the future. Thanks!”

Interesting e-mail exchange: HTML vs XHTML

It’s not really a wrestling match, but it is something of a face-off:


Email 1:
Dear Mr Noble:

I am writing a research paper on the difference between HTML and XHTML along with the advantages and disadvantages of the two. I am asking for your opinion because I have learned quite a bit about the languages reading your book HTML, XHTML & CSS for Dummies. From your bio in the book it seems you have a lot of experience and the book itself only proves that. So I was wondering, what is your opinion on HTML vs XHTML? Which is most efficient? Which is, in your opinion, the “best” and why?

Egad! We’ve Been Hacked

Wow! I hate to admit it, but we’ve found — and cleaned up — evidence of a WordPress-specific attack on this very Website recently. The signs showed up first in descriptive text about the site on Facebook, but then this morning we got word from one of our readers that active links to various payday loan sites were showing up through our home page. And sure enough when I went to “View Source” on that page, here’s what I found:

<p>Within the basic facts including payday cash than payday loanspaperless payday legal citizen of fraud or able to expedite the present valid source however there has <a href=”http://m*rtg*”></a> poor of bad credit borrowers who says it take on what faxless payday personal need some boast lower than average credit this occurs payday advance. Problems rarely check on it at cash advance <a href=”http://ch**” title=”cash advance”>cash advance</a> your will most needed. Low fee for school or worse payday loans <a href=”http://p*yd*” title=”payday loans”>payday loans</a> you gave the country.  …other similar text removed for brevity’s sake, asterisks added to URLs to prevent blockage or blacklisting…</p>

Jeff jumped up to the site and killed the offending injection into one of our primary header files that was causing the problem, and then turned up this fascinating article from Sucuri entitled “Common WordPress Malware Infections” from our friends and colleagues over at Smashing Magazine. We’ve put the Sucuri SiteCheck facility to good use to produce the following results report, too:

After some clean-up, a clean bill of health results.

After some scrubbing, a clean bill of health.

All of this information is presented to make some important points about web site security:
1. When you turn your platform over to a third party like WordPress you inherit all of its security weaknesses.
2. Keeping your site up to date includes keeping the platform up-to-date and secure, as well as the content.
3. Monitoring site security is easier to do that I originally thought, but also more important than I had thought as well (I have no trouble understanding why site operators pay for multiple daily security checks to limit exposure to exploits should they occur).

If they can hack us, they can probably hack you, too, so you’ll want to take steps to prevent such things from happening. Be sure to talk to your service provider about how they secure your environment, and ask them what steps you must take to help secure your website, too. To do otherwise risks embarrassing inclusions of unwanted content on your web pages (which is what happened to us) as a sort of “best case of the worst case.” But it could also result in users downloading malware when they access your pages, which in turn will either cause them to stop visiting your site (bad enough already) or make search engines like Google or Bing blacklist your URLs as malware infected (if you can’t show up in the engine’s search results, potential visitors can’t find you, which is an instant “kiss of death” for modern websites and thus a “worst case of the worst case” scenario).