HTML5: Hype, Substance and Scrutiny

Today we have a special treat: an article from Luke Stevens, author of The Truth About HTML5, that takes a critical look at the past, present and future of HTML5.

What is HTML5, really? How did it come about? Should we really be blindly following what we’re told about it or is some critical thinking required? Read on to find out.

Two HTML5s

HTML5 has, in its most buzz-wordy form, taken the world by storm, but all that is claimed to be “HTML5” isn’t. There is, in a sense, two “HTML5”s: the technical specification, and the collection of new and exciting technology that gets lumped in together as “HTML5”.

On the one hand, there’s the actual HTML5 specification — a lengthy technical document written largely for browser vendors that’s often a strange world for those of us who actually mark up web pages day in, day out. This is “HTML5” in the technically correct sense. (And really, is there any other kind?)


On the other hand, there’s HTML5 the buzzword — the collection of new (and not so new) technology that is often downright cool, but has little to do with the HTML5 specification or those who contribute to it. For example, have you seen the interactive, WebGL- powered music video for Danger Mouses’ Rome project? It all happens natively in your browser (except IE due to security concerns), and will make your jaw drop.

WebGL is new and sexy, but even old standards are being dusted off and made new again. Did you see the incredible SVG Girl animation in IE9? Microsoft’s hardware- accelerated support for the decade-old SVG standard has made things possible in SVG that we could only dream of ten years ago. And yes, that’s Microsoft pushing web standards to new heights.

But SVG — once heralded as “The New Flash” — isn’t HTML5 either.

What is HTML5?


HTML5, as a specification, is actually at its best when it’s at its most boring. The HTML5 editor, Ian Hickson, has gone to great lengths over many years to get the HTML standard into shape, so browser makers can implement it in a consistent way. Implementation details for browser makers is hardly sexy stuff, but it does make all our lives easier in the long run, and for that we can be thankful.

HTML5: The Good Stuff

In fact, it’s something of a small miracle that HTML5 exists at all. After declaring HTML 4.0 done and dusted way back in 1999, the W3C spent the first half of the 00s pursuing XHTML 2 — a dead end spec that Opera’s HTML5 evangelist Bruce Lawson described as a “beautiful specification of philosophical purity that had absolutely no resemblance to the real world”.

In 2004, a group working for browser vendors operating outside the W3C saw the future of HTML differently, and started working on evolving the HTML spec to better accommodate web apps, and released a position paper stating their intentions. After being rebuffed by the W3C, this group — the Web Hypertext Application Technology Working Group, or WHATWG — went on to develop the Web Applications 1.0 and Web Forms 2.0 specifications, edited by Ian Hickson under the “benevolent dictator” model of specification development.

Long story short, the W3C eventually came to their senses and realized that XHTML 2 was a dead end; the WHATWG had the support of those who really mattered (the browser makers); and they didn’t have much choice but to come on board and adopt the WHATWG’s standards.


The good parts of HTML5 largely reflect this history. For example, HTML5 was in part born of Web Forms 2.0, and therefore HTML5 contains new forms features that add a variety of features to significantly simplify form development, including the handy placeholder attribute among many others. You can see more about HTML5 forms browser support in the excellent Wufoo HTML5 forms guide.

There’s also a variety of web app-oriented features including the History API, which gives us a way to manipulate the browser’s history and address bar URL through JavaScript, and move beyond the ugly hash-bang (#!) URL schemes, and indeed the full page refresh model we’ve been trying to work around since the world of Web 2.0 and AJAX requests.

The HTML5 spec (and its forbearers) is edited*, as mentioned, by Ian Hickson. As Jeffrey Zeldman says:

“In reality, there is one ‘decider’ — the editor of HTML5, Ian Hickson. His decisions are final, he is under no obligation to explain his rationales, and he need not prioritize developer recommendations above a browser maker’s — nor above a sandwich maker’s, if it comes to that. By design, Hixie is a free agent according to the structure he himself created, and his browser maker end-users (masters?) like it that way.”

Hickson is not just the editor — he has also been a very significant contributor to the spec he edits, for better and worse. For example, that WebGL demonstration we touched on earlier uses OpenGL-based technology running through the element. The element was something Apple invented internally for simple, scriptable 2D graphics in its OS X dashboard in 2004. Later, it was added to Safari. Hickson reverse engineered and standardized it for other browsers.


Fast forward to 2012 and we have Microsoft sponsoring a browser-based version of the mobile hit Cut The Rope that uses — you guessed it — the element for its 2D graphics. Web standards sometimes come about in strange ways.

HTML5, The Not So Good Stuff


But what about plain old HTML tags — what does HTML5 add there? Well, this is the not so good part. HTML5 includes contributions from its editor/contributor (as both player and referee) in the form of new elements too.

You’re probably familiar with the new structural elements such as