October 01, 2012, 11:39 AM — The Worldwide Web Consortium (W3C) last week announced it will finalize HTML5 by 2014 and HTML 5.1 in 2016. With significant challenges ahead, the W3C laid out a tentative implementation plan. Should the plan be approved by the HTML Working Group the W3C will see 15 years of work culminate in not only HTML5.0 but its successor 5.1 as well.
The reasoning behind announcing two specs is the result of a different approach to the problems and setbacks the W3C has faced in the past. The W3C plans to step back from what it has dubbed a monolithic "kitchen sink" method with a grab-bag of features. Moving forward it will rely more on modularity in an effort to prevent setbacks and delays.
"The current combination of a monolithic kitchen sink specification, Decision Policy, A11y Task Force, and Formal Objection process has led to a significant number of objections, and current difficulties in achieving consensus." -- Worldwide Web Consortium
Related Article: 9 Programming Tools for Maximizing HTML5
Originally HTML5 included many pieces that have now been turned into their own specifications including Web Storage, Web Workers and the WebSocket Protocol. This approach will allow the W3C to move any unstable elements into the HTML 5.1 spec, thereby limiting what is in HTML5. With this approach the W3C can focus on making HTML5's current features interoperable between browsers and stable--something they have been working on for quite some time.
"Splitting out separate specifications allows those technologies to be advanced by their respective communities of interest, allowing more productive development of approaches that may eventually be able reach broader consensus" -- Worldwide Web Consortium
W3C's HTML5 Proposed Plan Outline
Split what was originally HTML 5.0 into an HTML 5.0 and an HTML 5.1, and considerably raising the bar on what issues and bugs we consider in the HTML 5.0 timeframe:
For bugs: create a new bugzilla component for HTML 5.0 stable/CR versions of the specifications, and only allow bugs to be created or moved in/to this component that address interoperability issues or can be addressed by a non-substantive change to the specification.