If there’s one thing which holds back HTML5 adoption, it’s confusion regarding the state of the W3C specifications. Consider the latest document; 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.
Let’s look at another example: are you using the innerHTML method in JavaScript? You are if you’re using jQuery or another library. Despite wide support, it was never considered a W3C standard until HTML5. Would you rip it out of your HTML4/XHTML1.0 projects?
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.
Craig BucklerCraig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.
