“HTML 5 is a mess”, said John Allsopp.
I agree. It is. It’s also several different kind of messes, not all of which are avoidable or bad. Let’s look at them.
The backwards compatibility mess
The first kind of mess is because it builds on HTML 4. I’m sure if you were building a mark-up language from scratch you would include elements like
nav (actually, HTML 2 had a
menu element for navigation that was deprecated in 4.01).
You probably wouldn’t have loads of computer science oriented elements like
samp in preference to the structural elements that people “fake” with classes. Things like
tabindex wouldn’t be there, as we all know that if you use properly structured code you don’t need to change the tab order, and
accesskey wouldn’t make it because it’s undiscoverable to a user and may conflict with assistive technology. Accessibility would have been part of the design rather than bolted on.
But we know that now; we didn’t know that then. And HTML 5 aims to be compatible with legacy browsers and legacy pages. This page is written in HTML 5, and although your browser doesn’t “understand” it, it it still renders it.
There was a cartoon in the ancient satirical magazine Punch showing a city slicker asking an old rural gentleman for directions to his destination. The rustic says “To get there, I wouldn’t start from here”. That’s where we are with HTML. If we were designing a spec from scratch, it would look much like XHTML 2, which I described elsewhere as “a beautiful specification of philosophical purity that had absolutely no resemblance to the real world”, and which was aborted by the W3C last week.
That’s one reason why HTML 5 a mess. It’s built on a mess.
The process mess
Specifying HTML 5 is probably the most open process the W3C has ever had. Different groups with different interests battle it out over the mailing lists. Competing variant specs are springing up: Manu Sporny is devising a spec that incorporates RDFa in HTML 5, while The Mighty Steve Faulkner is writing one addressing accessibility issues including alt text and summary attributes. I’m hopeful that these will all be merged together, while simultaneusly, parts of the spec are being split out into separate specifications where there are no dependancies, such as Web Storage and Web Database.
This amorphous process is messy. But, in my opinion, infinitely better than the ivory tower of XHTML 2 academia.
The spec mess
Then, of course, there’s the real mess that John Allsopp and Matt Wilcox complain about—imprecise, ambiguous specification or unnecessary restrictions.
Why the restrictions on the
time element? Why the overlap between
Why is the
nav element so loosely specified? (“Only sections that consist of major navigation blocks are appropriate for the nav element”—define “major”, if you please.) Why can you have
nav inside a
header and not in a
If these things bother you, you can do something about it—email the Working Group and make your feelings known.
I should clarify two things after some tweets and a Skype conversation with Lachlan Hunt. The first is in fairness to Hixie: he changed the definition of
nav to clarify that there can be more than one per page, and I agreed that the new defintion was an improvement. But, as I’m a self-confessed dimwit, I only realised later that the word “major” leaves ambiguity as well. So that’s my brain parsing slowly, not Hixie’s bad.
Secondly, and most importantly, I haven’t had some kind of damascene conversion to the anti-HTML 5 camp. I firmly believe that it’s the best way forward for an Open Standard that allows us to write richer web pages and applications. And I’m sure that no-one, especially those in the Working Group, believes it’s perfect already. In fact, the Working Group consistently call for developer participation in reviewing the spec.
To reiterate: bitching in blogs (like I’m doing now!) and on twitter is OK, but the best way to be sure that your views are heard is to mail to Working Group.