Hitting the HTML moving target
HTML5 fork has been happening for a long time
News over the weekend that the HTML5 standard would be forked into two separate tracks may have been slightly overstated: the fork has actually been a long time coming.
If there is a fork in the HTML5 process, it didn't start this last week; the actual split may ave begun in early 2011, when the Web Hypertext Application Technology Work Group's (WHATWG) Ian Hickson announced their own work on the HTML5 standard would not use versions numbers and would forever be known as just "HTML."
At the time, Hickson described WHATWG's approach to HTML as something more flexible than the other standard body working on the HTML5 standard, the World Wide Web Consortium (W3C).
"The WHATWG HTML spec can now be considered a 'living standard". It's more mature than any version of the HTML specification to date, so it made no sense for us to keep referring to it as merely a draft. We will no longer be following the 'snapshot' model of spec development, with the occasional 'call for comments', 'call for implementations', and so forth."
What kept the two implementations of HTML5 (which is what I will continue to call the next-gen of HTML unless I am specifically referring to WHATWG's implementation) in basic sync was the fact that both the W3C's HTML5 and WHATWG's HTML were being edited by the same person: Hickson himself.
But late last week, Hickson made the announcement to the whatwg] mailing list that [he would no longer be handling editing of the W3C's specs, which breaks yet another link between the W3C and WHATWG implementations--possibly the last vital one.
On one level, this is truly the further widening of a fork that started when the WHATWG consortium was formed in 2004. The secret origin of WHATWG is pretty straightforward: "Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born to become an avenging hero for the Web."
Well, that last part might be my addition.
If someone wants to argue semantics with me, Hickson called it a fork himself in his July 19 announcement, when describing the events that led to this week's action to clone all of the mutual W3C/WHATWG bugs for the specs into two separate sets--one for W3C's HTML5 and one for WHATWG's HTML.
"[In 2007 w]e renamed the specification 'HTML5', and the W3C began publishing a copy of it as well. Not long after, the W3C side of this effort decided to split their version of the spec into subspecs (e.g., splitting out the 2D canvas API, server-sent events, postMessage, etc), and for a while we tried to match that on the WHATWG side. The result was an increasing confusion of versions of the spec, so we eventually went back to just having a single spec on the WHATWG side which contains everything I work on, which we now call the "HTML Living Standard". Over the years, this document and the various documents on the W3C side have slowly slightly forked, as documented at the top of the WHATWG spec."
While Hickson is rather casual in tossing around the term "fork" in his announcement of leaving the W3C spec editing position, he later assured that this action is not operationally a fork. In an interview with The Verge, Hickson said:
"It’s certainly possible that the specs will fork, but it’s unlikely, or at least, unlikely to happen in a way that is harmful. The WHATWG spec is going to match what implementations do regardless (that’s what we do), and the W3C version has to pass the W3C Process, which requires proving interoperability."
That's a very fine hair to split, and I am having trouble buying it. It is no coincidence that two of the three founders of WHATWG--Google and Mozilla--are now big believers in the six-week release school of thought. The rapid-release scenario is much more compatible with a "living standard" HTML model rather than a "snapshot" model bogged down by a bureaucracy that might hold Chrome and Firefox back.
For me, "living standard" sounds a lot like "moving target," which means it's fundamentally not a true standard at all. Browser developers can work towards the WHATWG HTML implementation, call their products "HTML certified," and still be wildly different then their competitors in how sites are rendered. Or even crippled for other browsers.
It's already happening: the worst part of the old browser wars is back, with sites like this citing better compatibility with Google Chrome when you visit with another browser.
No one likes that fact that the W3C is so slow, and there are certainly efforts the Consortium can make to speed things up a bit. But part of the whole premise of a standard is taking your time and putting together something all developers can work towards.
If the target keeps moving, it will be difficult to hit, and even if you do, it will just move once more.
And with this recent split of spec and bug management, the WHATWG HTML target just started accelerating.
Read more of Brian Proffitt's Open for Discussion blog and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.