clock menu more-arrow no yes mobile

Filed under:

W3C and WHATWG finalize split on HTML5 spec, forking 'unlikely'

New, 53 comments

The W3C and WHATWG are splitting editing duties on their respective HTML specifications. While some believe that the change will lead to two forks of HTML, WHATWG editor Ian Hickson maintains that any forking is unlikely.

HTML5 Logo
HTML5 Logo

One final link holding together two versions of the HTML specification is being severed, as the W3C (the web’s largest standards-making body) and the Web Hypertext Application Technology Working Group (WHATWG) separate editing duties. Until last year, the WHATWG and W3C had essentially been working together on a single HTML(5) specification, but in January of 2011, Ian Hickson of the WHATWG described a new development model for web standards: the WHATWG would now focus on an evolving, "living standard," while the W3C would stick to producing static "snapshots" using its traditional numbered versioning system. Now, in an email sent to the WHATWG mailing list, Hickson provides an update on the split, explaining that while he had previously been responsible for editing both the W3C and WHATWG specifications, editing duty for the W3C’s version will now be handled by someone else. The specific changes are essentially implementations of those laid out by the W3C back in April.

Any forking is unlikely to be harmful

The changes finalize the split between the two specifications, but they’re not exactly surprising. The WHATWG was established by people from the likes of Apple and Mozilla to accelerate the advancement of web standards, so it makes sense for them to want more autonomy from the W3C, and the "living standard" model has already been in place for 18 months. And while there are worries that the split is going to lead to HTML forking, Hickson tells us the fears are largely unfounded: "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." He added that while conflicts are unlikely to pop up, if they do, it’s likely to be a case of one being less precise than the other. "Browser vendors will just know to use the more precise one."