One of the complaints about the W3C is that it didn't push the HTML standard forward fast enough. Now in a sudden announcement it plans to make HTML5 complete by the end of 2014 - but only by shrinking down what we mean by HTML5.

This might still seem to be a leisurely pace, especially when you take into account that it is just a draft plan for the recommendation for the standard. However standards committees never really do anything definite unless some party objects and draft and recommendation is about as firm as it gets.

Currently the draft plan is for an HTML 5.0 recommendation in 2014 Q4 and for an HTML 5.1 recommendation in 2016 Q4. You can tell that they aren't that sure the work can be done in time by the selection of the fourth quarter dates to give as much time as possible without having to admit that the time scale is actually closer to the following year - 2015 and 1016.

If you think that end of 2015 is still a long way off for a standard that we are currently using to be finished you need to recall that the previous estimate had been pushed back to 2022 i.e. a whole ten years from now. So the new plan should see things finished some eight years earlier.

The process is going to be speeded up by concentrating testing on the new features rather than wasting time testing what is already in place. This part is obvious, sensible and comparatively easy. However a major part of any standards committee's job is to get warring parties to agree. To quote:

"The negative tone of discussion has been an ongoing problem which has kept many potential contributors away from mailing lists and teleconferences. We therefore need to be more active in making it clear that anti-social behavior will not be tolerated in the HTML WG."

How is progress to be achieved?

"Use modularity to manage the size and complexity of the specifications while reducing social conflict within a constrained timeline."

Basically they are going to move everything they can't agree on in HTML 5.0 into HTML 5.1

The modularity idea is that specifications will be split into parts that can be implemented at once and parts that can't be but that don't affect the basic specification. These "extension" specifications will be pushed forward into HTML 5.1 and beyond.

The modularity will be used on a larger scale to split off extension specifications - things like HTML/XHTML compatibility, Canvas 2D context, webSockets, Web Workers, Microdata formats and so on.These will be allowed to progress at their own rates and achieve standardization as separate entities.

This is, of course, getting very close to the "HTML5 Living Standard" idea proposed and promoted by WHATWG.

The W3C is at pains to point out that the extension specifications are not second class citizens and that they are part of HTML5. Of course that's not how all of the browser makers will see the matter and they will probably feel free to pick what they implement. This will probably lead to more browser fragmentation and difficulties in saying exactly what we mean by the overused term "HTML5".

This all seems more realistic than continuing to argue for the next ten years in an effort to include everything into one big "HTML5" package. It makes it more difficult for programmers but at least we will have something, if not everything, standardized sooner.

Google Code-in is a contest that introduces teenagers to the world of open source. It takes place entirely online and is open to students between 13 and 17. Now in its seventh year GCI runs until Janu [ ... ]