Mozilla Standards Blog

At the Mozilla Summit, I held a session on Standards. The organizational powers that be gave me the Big Room, and before long I stood in relative darkness on stage discussing standards with the mavens within our community that pay attention to such things.

Now, standards are a big deal to us — everything we do here at Mozilla is, for the most part, a contribution to the Web platform. I blogged previously about the low esteem I reserve for arguments that favor proprietary platforms (which typically pit rapid proprietary innovation against dawdling Web Platform standardization cycles), but even in that upbeat blog post, I acknowledge that the standards process leaves much room for improvement.

My slides basically summarize the numerous places we go to build interoperable specifications, even though some of these places are theoretical at the moment (meaning we aren’t quite going there yet), and the activities we’re currently involved in. But, I was most interested in the audience participation part. That’s where I got to talk to folks working on stuff pertinent to standards, and to listen to their points of view.

Basically, many of the comments from the floor were in a plaintive vein. People love to air grouses about the standards process when given a chance. Some complained about having to read far too much email (on the W3C HTML5 WG listserv, for instance). I took a poll to see how many people followed HTML5’s progress exclusively on the WHATWG mailing lists, and how many people followed the progress of HTML5 on the W3C listserv. Slightly more hands went up showing a following of progress on the WHATWG listservs; a few people claimed to do both listservs. More than one person complained about the signal-to-noise ratio on the W3C HTML5 listserv, saying that there was a lot of cruft that burned up bandwidth and not enough really useful material to warrant the sifting. I tut-tutted sympathetically, but dealing with email isn’t just a standards involvement problem. I maintain that several were invited to W3C’s latest HTML party; few are experts. Some “topic sieve” mechanism for filtration is probably a good thing; there does seem to be relatively clean use of the email subject line, so developing a mail management strategy is really a mitigable problem (you’re on your own for that one, kids ).

Two general themes can be distilled from the open discussion we had:

• There continues to be the perception that W3C is too slow, especially given the rapidity with which Mozilla is moving. I asked an open question about where Robert O’Callahan’s cool SVG-in-CSS stuff should live. A modest amendment to the CSS charter? A W3C note? Or perhaps within the Compound Document Formats (CDF) WG? Naturally, we think it’s a great new capability to add to the Web platform — it’s an elegant stitching together of two standards, unleashed by an element id. Where should it live, though? How can it gradually become behavior that developers can count on? The pervasive sentiment was that the discussion of where it should live seemed prosaic, and that the time taken to even get it under way at W3C would be too long. The reasoning was that there would be a process impediment raised by those inimical to SVG or CSS doing things it doesn’t normally do (are there user agents that just don’t support SVG? Really?). WHATWG, however, just seems to get on with it. Maybe it was best off there?

  The argument that WHATWG moves much more rapidly than W3C is certainly true; WHATWG just doesn’t have closed door “Advisory Committee Review” sessions on charter amendments to deal with, and there isn’t really a lot of process overhead to getting a new idea put to text by a rapid editor. Even charter amendments to the successful W3C Web Applications WG would require an Advisory Committee Review cycle, which might result in lengthy discussions or a stalemate on controversial, “big patent” areas, like the Geolocation API, which will soon have its own working group. Who wants a stalemate? And few would venture that time spent waiting for a home for a new idea to live is time well spent, especially when you can just get on with it within the WHATWG.

• But every coin has a flip side. The big problem with the WHATWG is that Ian Hickson, its main editor (great guy) isn’t scalable (he’s mostly human, and this is a human failing). Plus, with one person as the gatekeeper of the important but floating HTML5 specification, disagreements are bound to arise. Those attending the summit did complain about changes to specifications that happened without their blessing — I heard terms like ninja insertions, and anecdotal stories about the rightness or wrongness of specification changes without a developer’s consent. For the most part, these dissipate with time — that’s just part of the process, which explicitly is NOT based on W3C-style consensus (by design). There’s a benevolent dictatorship at work here, which can be justified as being sound technically, but the fact of the matter is, you aren’t just dealing with an editor who puts in “majority rules” text. The editor is very, very opinionated. “Ninja insertions” in the specification can happen if you don’t monitor the email (which goes back to large cycles spent looking at email — just an occupational hazard, I suppose). Sure, WHATWG may be an imperfect system, someone pointed out, but it works and it’s fast.

So the two standards bodies which are of importance to Mozilla either have painful consensus building overheads or explicit legislation from the editor, both of which have pros and cons. Where’s the upbeat coda I promised, if there’s only problems and tricky nuances?

Actually, I took a poll of the audience to see who would be willing to edit specifications. The room was silent for a while, and then some of the usual suspects tentatively raised their hands. I’m upbeat not necessarily because I get to chase people up to do work and officially commit to documenting things for the Web Platform (which is great), but because of the number of people that attended my session, and because of the fact that as a community, we collectively spent an hour or so strategizing about future directions. The Web is a riotous assembly, too impatient for lengthy consensus cycles and too big to have a bottleneck of size one. We’ll work this out yet, and it will be imperfectly functional, with standards getting crafted in more than one place.