HTML5 Work Splits Into ‘Living’ And ‘Snapshot’ Standards. Developers Need Not Worry, Says Living Standard Leader

It’s not often in the mobile world that you hear of a split in standards development that doesn’t make you groan thinking of the complications that it will imply moving ahead (hello, Android!). But a new development for HTML5 will apparently do just that. The Web Hypertext Application Technology Working Group (WHATWG) and the World Wide Web Consortium (W3G), the two bodies working on HTML5, are parting ways with WHATWG taking charge of an evolving, “living standard” and W3C working on a more static “snapshot.” Some are already raising the issue of forking (“Overall this doesn’t seem to be a good development. It will no longer be possible to say exactly what HTML5 is,” writes developer Ian Elliot), but the head of WHATWG, Ian Hickson, told TechCrunch in an email exchange late last night:  “We’re probably going to make a lot more rapid progress now.”

(Quick background: HTML5 is the web-based, non-native mobile web protocol championed by Facebook, Opera and other developers for the promise of developing apps and other mobile content that works across different operating systems without significant customization or special code work. It still has a long way to go, though, before it’s as functional as a native platform like iOS or Android.)

The news of the split was described earlier this week by Hickson in an open letter on W3C’s forums, where he notes that over the years, the two sides have already been working on different parts of the standards. That separation of duties has meant that the two sides have “slowly slightly forked”, and now that has been formalized into an administrative split: one person responsible for editing the W3C HTML5 Canvas and specifications (yet to be named), and another editing the WHATWG specification (that will be Hickson, whose email signature tagline is “Things that are impossible just take longer.”).

We contacted Hickson to answer a few questions about what this might mean for developers, and for us users in terms of getting an increasingly better experience out of HMTL5 web apps. This is an issue for companies like Facebook, which in April revealed it had twice as many users of its HTML5 apps as it did its native iOS and Android apps, but that these users were limited in what they could do because of Apple and Google’s slow progress on the standard.

An interesting thing Hickson pointed out to me was that there is value in what both sides are doing. His side will be looking to put in more functionality, while W3C will be looking to make this something that can be appropriated by the tech world on another level: in the case of patents and contracts. Here’s the Q&A we had late last night:

TC: Will this split set progress back, do you think?

Hickson: No, quite the contrary. We’re probably going to make a lot more rapid progress now, because we’ve essentially separated the research and development part of the effort (working on new features, describing how things got implemented, and so on) from the technical report snapshot process, so the two parts of the effort do not need to block each other. (For example, it’s hard to keep adding new features when you’re trying to freeze the spec’s feature set!)

TC: What will companies like Facebook and Opera have to do going foward (both have put a lot of effort into HTML5).

Hickson: Nothing has really changed for developers, browser vendors, and people sending feedback on the spec. In theory it should only really affect the people doing the spec editing work. Browser vendors will still have to decide whether to follow the specs, just as they always did. Developers will still need to check what the browser vendors actually implemented, as they always did. People sending feedback on the specs can continue sending them to the same places they sent their feedback before; for the WHATWG side I will continue to monitor the same places, and for the W3C side I assume they will do likewise.

TC: How does the living standard work filter back into what W3G will be doing setting the standard?

Hickson: Both specs are “standards” in their own way; the WHATWG spec is what we call a “living standard”, meaning it is what we recommend that browsers implement and is updated based on feedback to fix any problems that we found as we find them, while the W3C spec uses a more traditional draft-draft-draft-snapshot model where once a version is released it is frozen and errors are typically no longer corrected. There are important uses for both; obviously the “always updated” version is good for making sure implementors and Web authors are working to the most up to date knowledge, but the snapshot model is also important, in particular for things like patent licenses (so that the lawyers know exactly what is being licensed), and for contracts (so that lawyers can agree on whether something matches what was agreed or not without having to worry about us changing the document out from under them).

Hickson also noted to me that the W3C has yet to make clear how it will track changes on the WHATWG side although it started discussing this as far back as April (you can see the posts from an Apple engineer working on W3C here, and a Microsoft engineer here calling for a new editor) .

On his side, Hickson says he plans to keep a close eye on the HTML working group’s deliverables, and will be taking into account any work they do. “There’s no guarantee that everything that the W3C does will end up in the WHATWG spec; the higher priority is that the WHATWG spec represent what implementors, mainly browsers but also editors and validators, implement (or will implement). So obviously if the W3C spec says something that doesn’t match “reality” it won’t make its way into the WHATWG spec.” He points out that this “isn’t an entirely academic concern, but hopefully it’ll be rare.”

We’ve spoken with one developer to get his take on this and he concurs with Hickson that the main priority here is what browser leaders will do, although he also thinks that “separation rarely indicates things are going well.”

“To a large extent, on the ground this potentially doesn’t matter,” says Matt Baxter-Reynolds, an independent software development consultant based in London. “From the developer’s perspective the idea that there is an ‘HTML5 standard’ is something of a myth. There is no ‘standard’, because it’s under development. Seeing as there are only three browsers in the world that actually matter – Chrome, Firefox, and IE – it’s really down to how the vendors implement proposals which is the important part. Where those proposals come from – W3C or WHATWG – shouldn’t matter.

“Saying that, separating rarely indicates that things are going well. It suggests to me that WHATWG didn’t like the W3C working method and it appears WHATWG wants to play faster and looser with the methodology. One of my key concerns about web standards generally is that the vendors have commercial imperatives. That desire to follow commercial goals first, standards second, was balanced out with the strong methodology from W3C. With that methodology being sidelined I wonder if we’ll see more splitting of capability as commercial goals are prioritised rather than working towards a defined standard. And splitting of capability rarely serves the consumer.”

This seems to be the crux of the situation: navigating through the choppy waters of progress while making sure everyone stays on board.

We are reaching out to both Facebook and Opera, two of the bigger names that have put a lot of effort into developing content on HTML5, to get their take on the situation.

[Image: NCBrian on Flickr, HTML5 logo]