HTML 5

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

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

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

,

,

and

, plus

and

. The first four all do much the same thing — they create a new section in a document outline. But as far as web designers and developers go, no one much knows what a correct “document outline” is, or why one should be created (it’s explained deep in the spec). In fact, my research suggests these new elements were seemingly drawn up on a whim by the HTML5 editor on a whiteboard in 2004 and, with a little feedback, finalised in the spec. Again, web standards sometimes come about in strange ways.
These elements may sound familiar, but the way they are specified is anything but familiar, and that has created a great deal of confusion. For example, if you look at the spec, you’ll see an example which suggests we use

for comments, and

for the header of those

s… I mean comments. Footers for headers? Articles for comments? It’s a bit of a mess.

Where do we go from here?

Over the last few years there’s been a lot of buzz around technologies related to HTML5, and plenty of buzz for some of the new features included in the actual specification.
Hype often obscures scrutiny, however, and some of the most fundamental parts of HTML5 — such as how we’re supposed to mark up a basic web page — have been poorly scrutinized and simply passed off as a fait accompli.

The Truth About HTML5

To my mind, that’s not good enough, and that is, in part, why I wrote The Truth About HTML5. There are many books, blog posts, and articles that discuss what’s in the HTML5 specification, but very few that discuss why it’s in there, and whether and how we should use it.
Hype isn’t a substitute for substance, and too often authors have just repeated what they’ve been told without digging deeper and asking the hard questions of the HTML5 specification. Therefore, I set about doing the research into the truth about HTML5, and came to some controversial positions along the way, particularly with regard to the new semantic elements, which I believe many designers and developers have unwittingly gotten horribly wrong.
I believe it’s our responsibility to be as informed as possible about what the HTML5 specification is truly about, and how it came to be. After all, if we, the ones who work with HTML5 day in, day out, don’t pay attention to what’s in the standard we all use, who will?
Author’s Note
*Ok, for those of you keeping up with the latest in W3C and WHATWG politics, the WHATWG declared their HTML5 specification to be a “living standard” called plain old HTML; and the W3C has stuck to their versioned, snapshot model of the more-or-less same specification, still calling it HTML5. (Confusing, huh?) Ian Hickson was editing both the W3C’s HTML5, and the WHATWG’s HTML “living standard”, but has since stopped editing the W3C’s version of HTML5 so others can cross the t’s and dot the i’s for the final W3C HTML5 snapshot, while he continues to work on the HTML living standard. In short, the future of HTML is still in one man’s hands.

Share this

Share on FacebookPlus on Google+