HTML5 and Modular Implementations

This morning, Tim Bray linked to an interesting discussion on HTML5 that’s been taking place the past couple days on Robert Sayre offered up a dramatically cut version of Ian Hickson’s HTML5 spec as a counter-proposal for HTML5, which caused a great deal of controversy (and head-scratching).

Sayre’s argument, as I understand it (which I’m not 100% sure of I do), is that the enormity of the HTML5 spec as-is makes it not work somehow, and instead we should use his version that omits much of all the new things in HTML5. It sits somewhere between being HTML4.1 (or “HTML4 done right”) and a crippled HTML5, really. One of Sayre’s arguments for why he did this:

“I don’t have any plans for the removed items. I don’t want to work on them, but I am certainly not trying to block them. In fact, there’s nothing stopping Ian from continuing as he has been–his document could supersede the document I’ve produced, but it’s going to take longer.”

Sayre seems to think, by my understanding, that the HTML5 spec needs to be implemented in one fell swoop in browsers or not at all. There is no acceptable middle ground. His intent thus appears to provide a stop-gap measure of a slightly-better-than-HTML4 approach that browsers could implement sooner.

The huge omission in his rationale, and again I must stress that this is purely my limited understanding of his limited explanations, is that there is such a thing as partial or modular implementation, and that this is not an inherently bad thing.

Just look at CSS3: it may not be perfect, it may not have everything you’d want (yet), but parts of it are being implemented by various browsers and they’re coming to a stage where those implementations are ready for use, now. CSS3 was admittedly pro-actively modularized because of the exact concerns that Sayre has over HTML5, but there is no reason, no reason at all, that the same approach could not be utilized by browser vendors when implementing HTML5. In fact, that’s already the case right now: WebKit/Safari has initial support for some of HTML5 (like <audio> and <video>) but not all of it. Is this a problem somehow? Not at all.

Just because HTML5 as a spec in its current state is not proposed in a modular way, like CSS3 is, doesn’t mean that browsers must implement the whole thing in one fell swoop. Sure, it may, as a result, mean that full conformance even for just the first browser will take many years, but I ask you, so what?

We don’t need full conformance before we can start using any of the things implemented. There’s nothing preventing you or me from using -webkit-border-radius and -moz-border-radius in websites right now, as long as we can live with the fact that not every browser will see that. Similarly, we can use what’s available in browsers from HTML5 right now, as long as we can live with having to use workarounds in some shape or form for browsers that don’t yet support them.

Robert Sayre may have a problem with that, but the Web as a platform does not. It’s worked for us so far, and it’ll continue to work for us going forward.

If you liked this, you should follow me on Twitter!