W3C was just announced the 2014 delivery plan of HTML5. It is a significant milestone of new standard development. When will the new standard delivered? How does it affect you? Whatâ€™s the response of the public? Letâ€™s have a check.
If thereâ€™s one thing which holds back HTML5 adoption, itâ€™s confusion regarding the state of the W3C specifications. Consider the latest; itâ€™s a â€œWorking Draftâ€ with big red â€œwork in progressâ€ warnings.
Many developers claim itâ€™s impossible to adhere with standards when the guidelines are in a state of flux. The W3C poured more fuel on the fire when they stated final HTML5 Recommendations would not arrive until 2022. For many, this meant sticking with HTML4 or XHTML1.0 for another decade.
2014 â€” the New HTML5 Completion Date
The W3C has a new plan: HTML5.0 will reach Recommendation status by the end of 2014. All features which are stable and implemented in multiple browsers will be finalized and included within the specification.
New and unstable features will be considered for HTML5.1 which will reach Recommendation status by the end of 2016. And we can presume this cycle will continue for HTML5.2 in 2018, HTML5.3 in 2020 and so on.
In addition, the W3C will cut the size and complexity of the specifications with modular standards. Technologies such as canvas, Web Sockets and web storage will be become discrete projects which do not necessarily follow the HTML5.x schedules.
How Does This Affect Me?
Do you consult the HTML5 specifications before starting a project? Why?
Despite the name, W3C specifications are not the same as software specifications. To reach â€œRecommendationâ€ level, a technology must be consistently implemented in two or more browsers. They should be followed if you were building a new browser but, for the rest of us, it simply means a feature has a reasonable level of support.
However, features in W3C Recommendations do not imply implementation consistency in every browser. This statement may shock some but, in the case of your project, W3C specifications are irrelevant. Before you use a feature you must determine whether:
- itâ€™s supported in all browsers
- itâ€™s implemented consistently
- there are shims or workarounds for browsers without support
- it is likely to change or be dropped in future
- alternative technologies offer better options.
Consider something simple such as the header, footer, article and nav elements. These are supported in every modern browser. IE8 and below donâ€™t recognize them, but HTML5 shims can solve that for you.
Would you really abandon the nav element until 2014 (or 2022 if youâ€™re following the old schedule)? Itâ€™s usable today and, while it could be scrapped, the same could be said of any element. Even div could become deprecated one day.
HTML is continually evolving. Itâ€™s a moving target â€” but so is every other technology. W3C specifications offer no guarantee of browser support and the documents are out of date the moment they are published.
Plan 2014 reduces W3C approval times. Itâ€™s edging toward the WHATWG notion of a living HTML standard but provides the schedules and deadlines people like. So itâ€™s all good â€” but means very little to anyone developing HTML5 applications.