HTML5 business as usual
It’s been a strange week in HTML5. The web—and Twitter in particular—has been awash with wailing and gnashing of teeth as various people weigh in with their opinions on either the W3C or the WHATWG—depending on which camp they’re in—being irreversibly broken …exactly the kind of ludicrous over-reaction at which the internet excels.
This particular round of chicken-littling was caused by the shuffling of some spec components. The W3C HTML Working Group recently decided to split microdata into a separate specification (which I think is fair enough given RDFa’s similar status). Hixie then removed some other parts of HTML5; a move which was seen as a somewhat petulant reaction to the microdata splittage. Cue outfreakage. Before too long, most of the changes were rolled back.
So all of the shouting and arguing was more about politics and procedure than about features or semantics. That’s par for the course when it comes to the HTML Working Group at the W3C; the technical discussions are outweighed by the political and procedural wranglings. But that’s the nature of the beast. Hammering out a standard is hard. Building consensus is really hard. The chairs of the working group face an uphill struggle every single day. Still, that’s a far cry from declaring the whole thing a waste of time.
As Tantek points out, if the HTML5 shenanigans seem particularly crazy, that’s only because they are that much more public than most other processes:
The previous several revisions of HTML (including XHTML) were largely developed in W3C Members-Only mailing lists (and face-to-face meetings) which contained a lot of similar “corporate politics, egotism, squabbles and petty disagreements” - however such tussles were invisible to search engines, the general public, and of course all the professional web developers and designers (like yourself) - you never saw how the sausage was made as it were.
Tantek was responding to a post by Malarkey who advises us to keep calm and carry on. That’s sensible advice, although he gets some push-back in the comments from people concerned about a market-led approach to web standards, wherein we only care about what browsers are implementing, not what’s enshrined into a standard.
It’s easy to polarise this issue into a black and white dichotomy: implementation first vs. specifications first. The truth, as always, is much more nuanced than that, as beautifully summed up by Rob O’Callahan:
Implementations and specifications have to do a delicate dance together. You don’t want implementations to happen before the specification is finished, because people start depending on the details of implementations and that constrains the specification. However, you also don’t want the specification to be finished before there are implementations and author experience with those implementations, because you need the feedback. There is unavoidable tension here, but we just have to muddle on through … I think we’re doing OK.
I think we’re doing OK too.
Not that I’m not immune to HTML5-related temper loss. Most recently, I was miffed with the WHATWG rather than the W3C but once again, it was entirely to do with specification organisation rather than specification contents.
The WHATWG have never been comfortable with the term HTML5 to describe the work they’re doing, which began life as Web Apps 1.0. The very idea of version numbers is anathema to their philosophy so they’re quite happy for the W3C to own the term HTML5 to describe a particular set-in-stone markup spec. But they still need a word to describe the monolithic ongoing WHATWG spec.
Historically, the term HTML5 was a pretty good fit for the WHATWG spec and it corresponded exactly with the W3C spec (in fact, the W3C spec is generated from the WHATWG spec). But Hixie declared Last Call for the WHATWG HTML5 spec a while back. That means that the specification at the WHATWG and the specification at the W3C can now diverge—the WHATWG spec contains everything in HTML5 and then some. To continue to label this WHATWG spec as simply HTML5 would be misleading. So a few weeks ago, the name of the spec changed from HTML5 to WHATWG HTML (including HTML5).
Accurate as that designation may be, I became very concerned about the potential confusion it would cause. Any front-end developer reading a document titled WHATWG HTML (including HTML5) might reasonably ask
Oh, which bits are HTML5? …a question to which there’s no easy answer because at the WHATWG, the term HTML5 is seen as little more than a buzzword. In that sense, they share PPK’s assertion that
I was particularly concerned that the short URL http://whatwg.org/html5 would redirect to a document that wasn’t called HTML5. I could point developers at this diagram but I’m not sure that it would make things any clearer.
Things got fairly heated in the IRC channel as I argued for either a different redirect or a better document title. I understand why the WHATWG need to transition from using the term HTML5 to simply using the term HTML to describe their all-encompassing ongoing work, but flipping that switch too soon could cause a lot pain and confusion. A gradual evolution of titles reflecting the evolution of the contents seems better to me:
- HTML5 (including next generation additions still in development)
- WHATWG HTML (including HTML5)
- WHATWG HTML
Hixie made the change. The title of the WHATWG specification is currently at step 2. I think this will make things a lot clearer for authors.
- Anyone looking for the specification that will become a W3C candidate recommendation called HTML5 should look at the W3C site: http://dev.w3.org/html5/spec/.
- Anyone looking for the ongoing evolving specification that HTML5 is a part of should look at the WHATWG site: http://whatwg.org/html5.
I’m happy that this has been cleared up and yet I hope that smart, savvy front-end developers who have read this far will think that I’ve just wasted their time. That would be a healthy reaction to reading a bunch of irrelevant guff about what specifications are called and how they are organised. Your time would be far better spent implementing the specifications and providing feedback.
That’s certainly a far better use of your time than simply shouting