Susan Hall interviewed Google's Ian Hickson, who serves as full-time editor for the HTML5 specification for the both the Web Hypertext Application Technology Working Group and the Worldwide Web Consortium.
Hall: So the Web Hypertext Application Technology Working Group (WHATWG) is separate from the Worldwide Consortium (W3C)?
Hickson: The WHATWG was started in 2004 by a few of the browser vendors because the W3C didn't want to work on HTML5. Now we're a mailing list with over 1,000 subscribers. Since 2007 or so, after the formation of the W3C HTML Working Group, we've been working together with the W3C on the development of HTML5.
Hall: How does that work?
Hickson: We influenced the creation of the W3C's HTML working group quite heavily, and so the group is quite different than most W3C groups. For example, it is much more open -- it has about 350 participants today and is working at a much faster rate. Instead of having a meeting once a week where decisions are made, we have a mechanism where editors respond to feedback asynchronously, and so meetings are unnecessary for progress.
Thus, it can be tense at times; people who associate with the W3C and not the WHATWG tend to come from a very different philosophy of specification development than people who associate with the WHATWG. For instance, in the HTML5 work, we've had a strong preference toward making decisions based on research and reasoning, whereas there's a history in the W3C of deferring to domain-specific experts. So, for example, where previously a spec writer would just ask an expert what the right behavior should be and get an answer as if from an oracle, now we try to reason out what the right answer should be based on testing implementations, doing studies to find out what Web authors and users are actually doing, and so on.
As you can imagine, some of the experts aren't too happy that we're now questioning their suggestions instead of blindly following their advice.
Hall: Will the work of the two groups come together at some point?
Hickson: We're already working together on a single joint document.
Hall: How much closer does this latest draft put you toward being finished with the specification?
Hickson: The specification is edited in the public, so there's not really any specific dated drafts per se -- for example, just today I made nine different changes.
The current plan is to be finished with all the current feedback by October. At that point we want to have a wider call for comments, where people hopefully report any errors they can find in the spec. Generally this can take a few years to go through, depending on exactly how much feedback we get. After October the main question will be how quickly browser vendors can implement what we have.
Of course a specification like this is never really "finished," I'm sure we'll be maintaining this, or its successor, for years or even decades to come.
Hall: I got this description from the FAQ: "HTML5 is a new version of HTML 4.01 and XHTML 1.0 addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications." Can you give me some examples of issues with those specifications?
Hickson: HTML4 was a remarkably vague specification. The most obvious example of something that it didn't cover was how to handle errors in documents. One misplaced angle bracket, and browsers were on their own, with the specification not saying how they should react. With HTML5, we've got a whole section on exactly how to handle every last syntax error.
Similarly, HTML4 doesn't actually go into very much detail about how headings and subheadings work, but in HTML5, we have a whole section on exactly how you derive a document's outline.
Both of these examples are also examples of areas where the culture clash I mentioned before, between people who associate with the W3C and not the WHATWG and people who do associate with the WHATWG, have really come to the fore. There are a number of people who believe that we should, in fact, not define how error handling is to be done, or that it's OK for a specification to be vague about the exact meaning of documents. Personally, I haven't yet really understood why. It seems so obviously bad to be vague!