Summary: Luke Stevens has crafted an excellent history as to how HTML5 got to where it is, and the compromises, retreats and reconsiderations that have been made along the way. The book is a critique of this process and its results, and attempts to put together the jigsaw pieces of the HTML5 API spec into a coherent picture. However, Luke's work is definitely not a development manual, and some of its recommendations should be seriously questioned.

Luke admits up front that The Truth About HTML5 is at least partly a diatribe against the status quo. That’s fine: while I’d almost always prefer to see someone try to change a process from within, there’s always a role for critics. Politics will be present whenever two or more people form an organization, and Luke has assembled a series of references that show how the political process played a part in forming HTML5, without getting too bogged down in detail.

The book begins to falter a little when it suggests an HTML5 web development process. For the most part, the author suggests abandoning many of the new tags that make up the HTML5 spec. His primary objections appear to be:

1. The syntax is complicated;

2. Because of that, web developers are misunderstanding / misusing it;

3. IE 6 – 8 doesn’t understand it, and JavaScript shims that force it to do so can be circumvented.

On the first two points, I have news for Mr. Stevens: as simple as HTML 4 purports to be, people have been misunderstanding and misusing the language for a decade.

Go out to a web site and do a View Source on a page sometime. Hell, try to validate most any page. The result is a mess of uninformed code: nested <blockquote> tags to indent content, <b> used inside of heading elements to “make them stand out more”, pages with presentational tables (which is still being taught as “the way to do page layout” by web development teachers today).

Every version of HTML is complicated. Coding a web page well is hard. HTML5 makes it easier, if the spec is communicated clearly to the developer. To be sure, WHATWG, the W3C, and indeed most resources have done a poor job of that – the lack of good, consistent, up-to-date web development reference material was one of the primary reasons I started this blog. But a paucity of any of these things is not a cause for surrender, only a reason to try harder.

We use markup because it has meaning – <p> tags rather than multiple <br>’s – and because it’s the right thing to do. New elements such as <section> and <article> have meaning too, and a place in the web developer’s arsenal. These new tags will become especially important as pages become atomized: using them correctly now “future proofs” your work, to a certain degree.

In his defense, Luke suggests a decent intermediate solution: using <div> tags with added ARIA Landmarks for accessibility. As a compromise for the confused, it makes sense – and the addition of accessibility is to be lauded – but he has neglected one obvious strategy, which I’ll discuss in a moment.

The Audience Is Listening

If the audience for your website is, for whatever reason, stuck on earlier versions of IE, and they refuse to upgrade the browser or install ChromeFrame, then Luke’s  approach of sticking with old reliable markup with accessibility makes sense for a particular audience stuck in the Digital Dark Ages.

But by way of comparison, let’s look a chart of visitor’s browser use for this website over the last 30 days: that little aqua segment represents IE users to my blog, less than 4% of this site’s traffic. Of those, only 80 visitors used IE8 or below.

I recognize that this site is something of an outlier: its content caters primary to web developers, who are, for the most part, using modern browsers. Visitors using IE 7 & 8 on this blog are outnumbered more than 20 to 1 by mobile users, most of whom use browsers that follow modern standards.

The question of “what technology should I deploy in my site?” is answered by “what browsers your visitors use?” Should I drop HTML5 features that have real advantages for users in preference to those who can’t, or won’t, move on? Should I invest in making a responsive site for 2,000 monthly mobile users, or instead use my time to make the site work better for the two lost souls who came in using IE6?

In an ideal world the answer would be “make changes that benefit everyone”, but there’s simply never enough time.

A Better Solution

Transferring old habits to new technology is not a way forward. Rather than dropping semantic markup as Luke recommends, my suggestion would be to take the best of both worlds: semantic HTML5 markup with ARIA roles and microdata/microformats, so long as it is appropriate to your audience. The richness, variety and occasionally confusing nomenclature of the specification sometimes makes this difficult. Luke quite correctly points out that outlining an HTML5 document is almost as important as validation, and doing so early and often should be emphasized during your planning and development, together with accessibility. Understanding how modern web technologies fit together is very important, and Luke does a good job of explaining the pieces, but there are few practical examples of how to apply the languages in the book.

Conclusion

Luke deserves credit for self-publishing an ebook on a complex subject. Until an academic historian comes along, The Truth About HTML5 is probably the best book you will find on the complex story behind the creation of modern web technologies. It does best in the realm of “big picture” explanations, but is ignorant of some topics (Luke expresses surprise at discovering the <address> tag, which has been around since HTML 3.2), while misrepresenting other issues. As an eagle-eye view of the current state of web technologies, it’s fine; for practical, real-world application of code, there are plenty of better, free alternatives such as Dive Into HTML5 and Designing For The Webtogether with real books (such as HTML & CSS by Jon Duckett, which I am currently reading, and will the source of my next review) and, I might humbly suggest, this blog.