Thoughts on Ruby’s “HTML Reunification”

I was off-the-grid when Sam Ruby of IBM, co-chair of W3C HTML Working Group wrote an essay on HTML 5 which sparked many comments, followups. Some of it went off into details, but here are some of the higher-level ideas I pulled out of it.

Sam starts by describing how the current HTML5 proposals fall into two camps: new features for browsers, and then how existing features should actually behave. The difficulties lie in that latter half — even small details like whether quoteblocks should assume quotemarks aren’t yet standardized in the spec, or in the world.

But it was a rephrasing a little later which really resonated with me:

TV Raman made a comment a number of times that we need to partition the idea of extensibility into two parts: extending the platform vs. extending the language. Those two words didn’t make much sense to me, but his examples did. Video and 2D graphics are things that need to be implemented by the browser vendors. And care needs to be taken that such features are defined in a way that they interact consistently with how other parts of the platform interact with other components such as CSS. Raman refers to these as platform features.

The second type of feature is one that does not need any support by browser vendors other than to simply to parse the unknown elements and attributes into a DOM, and to provide access to the DOM via JavaScript. RDFa comes to mind as such a feature, as does ubiquity-xforms. TV Raman refers to these as language features.

I like and endorse TV Raman’s split. Different burdens of proof and policies need to be applied to each type of feature.

He goes on to say that for new types of features to actually be usable by developers, “consensus by browser vendors is essential” — minority browser-vendors risk forking the Web; realworld adoption and practical deployment must be addressed. For language improvements, I think he wants to see better error-reporting to the user if some markup isn’t recognized.

But the part that struck me was how much of the current HTML5 discussion falls into two distinct sets: new “platform” features, and better handling of existing language features. For too long, runtime makers have added non-standard features, pushing the testing costs back onto content developers — the DHTML Feature Wars gave us a decade of web developers sweating out the differences. There’s a similar dynamic emerging today. But what serves the needs of vendors does not necessarily serve the needs of developers.

In reading some of the spin-off essays, I was particularly struck by this passage, from Rob Sayre of Mozilla:

“I don’t see a problem with HTML5 and XHTML2 continuing their separate ways. I do see a problem with some features being made part of HTML. Examples include a laughably underspecified SQL syntax, a video element that isn’t interoperable, and an RDF syntax that uses namespaces in text/html and QNames in content. Maybe we can all agree that those examples don’t belong in the HTML specification at this point. But then the problem shifts to one of endorsement. People want the HTML specification to tell them what they’re doing is OK. I don’t think the HTML document should do that either.”

That last point is key — if the VIDEO tag doesn’t actually serve content developers, then who does it serve, to warrant such attention? The most reasonable hypothesis is that the standards process is being used to “bless” the multimedia runtimes browser vendors want to create and control. We’ve seen it happen with the OOXML controversy, where standards bodies were used to bless a technology in the marketplace.

Endorsement of a browser vendor’s needs. That could explain why much of this is being pushed through, despite the apparent costs to content developers and their audiences.

I went through all the comments — painful reading, but I’m glad I did, because it revealed this little section of different perspectives from those seeking HTML runtime adoption, and those with a more pragmatic perspective:

Brad Neuberg of Dojo expresses the “HTML5 must have shiny features” position:

“If we follow Rob’s disassembly of HTML 5, there won’t be anything there to actually drive adoption. Sam, you suggest that his version has well-defined error semantics…. that didn’t work too well for XHTML though to drive adoption. We need a real-world standard with compelling features to keep up with Silverlight, AIR, etc., not an academic document that simply cleans things up. Unfortunately that’s not enough.”

Karl Dubost of W3C, in reply:

“This is a noble goal, but it really looks like a Geek Wet Dream. There are awesome things done with Canvas, but the thing that the hardcore geeks of html5 tend to forget that it is still far beyond what the Flash or Adobe Air platform propose. I’m not advocating for them. I really wish it was different. You can definitely say that canvas is a baby step for making an application platform to compete with adobe air in 15 years indeed. (Though don’t forget the competition will advance.) But selling canvas and some of the features of html 5 as a competitive technology with regards to the others make us (people in the HTML 5 WG) ridiculous.”

Brad seems to like Flash and AIR, but it’s not clear why he wants to force all browsers to try to duplicate such functionality. If vendors are still arguing over how simpler text features “should” work, then that seems a more pressing problem to solve.

One Response to Thoughts on Ruby’s “HTML Reunification”

  1. Arlen says:

    I’m in Neuberg’s camp, at least partially, on this issue. I’m not thinking in terms of Flash/Air/Silverlight though. I’m thinking more in terms of chronological impact.
    If we divide the spec, basically into “things we can directly see” and “things we cannot directly see” (which is how the division appears to me) and then spend the initial years working on the unseen, after the the seen things finally reach the spec, we’ll still have to wait more years for them to trickle out to the installed base.
    OTOH, if we do first the seen things, such as the new elements, canvas, etc., then they will start trickling out now and will be in a larger portion of the installed base sooner, so we can start reaping their benefits sooner. It also seems, from comments made by Ruby and others, that implementing a lot of the new elements is a simple task for the manufacturers, which seems to me an even better reason to grab the low-hanging fruit and score a quick win for HTML5. It’s those small but quick initial victories that increase the chance a platform gets accepted.
    I said partially, because I’d rather get the whole thing in place, even if I knew it meant waiting a decade for full implementation (heck, it’s been over a decade since HTML4.01, and it’s still not at completion, as defined by the HTML5 group as target for 2022). It gives a relatively future-proof path forward.
    I was more disturbed by all the talk of dispensing with authoring specs and simply focusing on language specs. To me, that dichotomy was one of the more useful bits. HTML was implemented with Postel’s Law in mind (“be conservative in what you do, be liberal in what you accept”) but only the latter half of that law seemed to make it into practice. The HTML5 authoring specs codify the first part of Postel’s Law, finally, and I’d like to see that continue.