The HTML5 Equilibrium

August 2nd, 2009

HTML5 is a strange character with what appears to be a split personality. Hardly surprising then that something so divided would appear to be so divisive.

First of all, there’s the spec itself.

The specification

HTML5 walks a fine line between maintaining backward compatibility with existing markup and forging the way as a modern, updated specification for the future. If it strays too far in paving the cowpaths and simply codifies what authors already publish, then the spec would mandate using tables for layout and font elements for presentation because that’s still what most of the web does. On the other hand, if it drifts too far in the other direction, the result will be something as theoretically pure but as practically useless as XHTML2.

The server would use neither a persistent connection nor a store-and-forward model, thus giving it all the worst features of both telnet and e-mail.

The hypertext model would ignore all serious theoretical work on hypertext to date. In particular, all hypertext links would be one-directional, thus making it impossible to move or delete a piece of data without ensuring that some unknown number of pointers around the world would silently fail.

And yet the web succeeded because:

…of the various implementations of a worldwide hypertext protocol, we have the worst one possible.

…democracy is the worst form of government except all the others that have been tried.

Which brings us nicely to the subject of governance and process, another area where HTML5 appears to be split.

The process

Democracy—or at least, consensus—drives the process of most W3C specs. But HTML5 isn’t just being developed at the W3C. HTML5 is also being developed by the WHATWG. Sounds crazy, doesn’t it? The reasons for the split are historical—the W3C rejected HTML as the future of the web in 2004 so the WHATWG started their own work and then the WC3 had a change of heart in 2007. Hence the parallel development. It turns out to be a pretty good system of checks and balances. The editors on the WHATWG side—Ian Hickson and Dave Hyatt—are balanced by the chairs on the W3C side—Chris Wilson and Sam Ruby.

The WHATWG process isn’t democratic. There’s no voting on issues. Instead, Hixie acts as a self-described benevolent dictator who decides what goes into and what comes out of the spec. That sounds, frankly, shocking. The idea of one person having so much power should make any right-thinking person recoil. But here’s the real kick in the teeth: it works.

In theory, a democratic process should be the best way to develop an open standard. In practice, it results in a tarpit (see XHTML2, CSS3, and pretty much any other spec in development at the W3C—not that the membership policy of the W3C is any great example of democracy in action).

In theory, an unelected autocrat having control of a specification is abhorrent. In practice, it works really, really well …if it’s the right person.

That’s always been the case with benevolent dictatorships. The populace transfers moral responsibility to the Leviathan of the state, personified by an-powerful ruler like Shakespeare’s Henry V:

If his cause be wrong, our obedience to the King wipes the crime of it out of us.

That’s a lot of responsibility for one person to carry. Remarkably, Hixie carries the weight with exceptional disinterest and a machine-like even-handedness:

But it doesn’t always seem that way to those on the outside looking in at the HTML5 process. Debates around the summary attribute or RDFa might well give the impression that Hixie is ignoring voices in opposition. Nothing could be further from the truth. The real challenge is in finding good solutions to problems, and sometimes that doesn’t necessarily mean using an existing solution—despite the pave the cowpaths mantra.

If you have a potential solution to a problem in HTML5, the way to present it is with data. If you don’t have the data, then maybe it isn’t such a good solution. I’ve experienced this myself with the rev attribute, which has been removed from HTML5. I think it should remain. I think it’s a potentially powerful attribute. But I can’t argue with the data. My personal preference isn’t a good enough reason to keep it (‘though I may occasionally tip out some beer to honour its memory).

The irony is that HTML5 has the reputation of being a spec beyond the influence of the average web developer when in fact it has the most open process of any web standard. If you want to have a say in the development in CSS3… well, good luck with that. If you want to have a say in the development of HTML5, you can.

Unlike just about every other W3C activity, the HTML working group is open to the public. You can join in as a public invited expert—except you don’t actually get invited. Instead you’ll need to complete this three-step process:

But a lot of the activity on the W3C side of things is very much about the process of developing a spec; voting, consensus and meetings. To have your say in putting the content of the HTML5 spec together, join in the WHATWG activities.

Firstly, time is of the essence. HTML5 is due to enter Last Call Working Draft in October of this year. From then it’s going to be a race towards Candidate Recommendation in 2012. If you want to influence this spec, now is the time to get involved. Don’t wait. The FUD around the boogieman date of 2022 is proving to be a particularly virulent meme that web developers have latched on to as an excuse for not caring about HTML5.

Secondly, you might be surprised by the contents of the specification. This is yet another area where HTML5 displays a split personality.

The feature set

Traditionally, HTML has been a format for semantically marking up hypertext—the clue is in the name. That’s still true but HTML5 is also a format for creating web applications; the WHATWG work that became HTML5 started life as a spec for web apps. This means that a lot of the discussions on the mailing list are about APIs, DOM trees, and some fairly code-heavy stuff around canvas and video. Discussions of the semantics of new structural elements like header, footer and article aren’t nearly as prevalent—all the more reason for working web developers to get involved in the process.

The truth is that much of the HTML5 spec isn’t aimed at web developers at all; it’s aimed at browser makers. This has fostered some conspiracy theories about how browser makers are controlling the spec but the truth is that browser makers have always had the final say in what gets implemented. It doesn’t matter how perfect a web standard is if nobody can use it. Hixie, for all his apparent power, acknowledges this:

I don’t want to be writing fiction, I want to be writing a spec that documents the actual behaviour of browsers.

Fortunately we don’t have to wade through a spec aimed at browser makers. Michael Smith has taken all the author-specific parts of HTML5 and published them in a parallel document: HTML5: The Markup Language.

The first type of feature is something that requires significant effort from browser makers; canvas, video, and all the new APIs. The second type of feature is something that requires very little effort from browser makers but is enormously significant for authors; header, footer, article, etc.

The diagnosis

HTML5 is the web equivalent of a circus tightrope act, performing equal feats of balancing and juggling

backward compatibility with shiny new features,

W3C consensus with WHATWG benevolent dictatorship,

and new browser features with new semantics.

It’s hardly surprising that such a schizophrenic spec can seem so confusing. If you spend some time immersing yourself in the world of HTML5, most of this confusion will evaporate. If symptoms persist, I recommend consulting the HTML5 doctor.