The announcement was made by specification editor Ian Hickson. His blog post states that the HTML standard has become a living document:
- The specification will be known as “HTML” with the URL http://whatwg.org/html.
- The WHATWG HTML specification can now be considered a “living standard.” It’s more mature than any version of the HTML specification to date, so it makes little sense to refer to it as a “draft.” The snapshot model of specification development has been abandoned.
What About the W3C?
The WHATWG announcement came two days after the W3C launched their HTML5 logo.
The term “HTML5″ is unlikely to disappear since the W3C standards approval process is structured around a progression of version-numbered technology specifications. Currently, the W3C remains committed to HTML5 and they won’t necessarily follow WHATWG’s lead.
However, the new logo has muddied the waters, and the W3C appears to be lumping CSS3, SVG and JavaScript APIs under the HTML5 “brand.” Although they’ve backtracked a little on their logo FAQ, it’s becoming increasingly difficult to refer to HTML5 as a specific technology when its own standards body has jumped on the marketing bandwagon.
Do We Need Version Numbers?
Many developers expressed their surprise and horror at the WHATWG’s notion. IT revolves around versioning. Development will descend in chaos without those digits. How will we know when a browser reaches compliance? How can we test code against a specific version of HTML?
Don’t panic. Dropping version numbers may feel unnatural, but web development always has and always will be based around a disparate set of ambiguous technologies.
There’s a widespread misconception that the W3C writes specifications for vendors to follow. This leads many developers to the conclusion that HTML5 won’t be ready while those documents are labeled “draft.” In reality, browsers are continually updated. HTML features are added and, if they’re considered good enough, they’re shared with or copied by other vendors. It will only be documented in the specification once two or more vendors have implemented the same feature. In the majority of cases, a feature will be usable before it’s documented.
HTML version numbers contribute to the confusion. It feels wrong to write code based on a “draft” HTML v5.0 specification. But consider this: XHTML 1.0 is “final,” yet it won’t be supported in Internet Explorer until version 9. Similarly, CSS2.1 is complete, yet no browser offers a full bug-free implementation. Finally, if you’re using stable CSS3 features such as rounded corners, why is HTML(5) any different?
Today, all the browser vendors claim HTML5 compatibility. However, it’s to wildly differing levels and no one supports everything. There are numerous browsers on desktop, tablet, mobile, gaming and other platforms. Each has a different set of features and evolves along its own path. You’re free to wait for the magical day when the specifications are complete and have been fully implemented by all vendors, but you’ll be waiting a long time. Even when that day arrives, browsers will have moved to the next technological level.
It’s controversial, but I agree with the WHATWG. All-encompassing version-numbered specifications have become too large and unwieldy to be practical. Fortunately:
- No vendor has a browser monopoly nor can they (easily) sway standards in their own direction.
- The main browser vendors are working with each other. They are innovating individually but must share ideas with others to ensure a feature becomes an accepted standard.
- HTML evolution is (mostly) backward compatible. For example, all browsers accept the new
<input type="email">tag but older editions will revert to<input type="text">. - Vendors rarely remove technologies from their browsers. Google is ripping H.264 video support from Chrome but, in general, HTML code will remain operable in the browsers in which it originally worked.
- We’ll always require feature detection. You can never depend on the availability of every HTML tag, CSS, JavaScript, SVG, Canvas, Flash or any other technology. Where necessary, you can detect its presence and provide alternative content. That situation won’t change — even when the HTML5 specification is complete.
A living HTML specification reflects the current state of web technologies today.
Do you agree? Will it work? Comments welcome…
Source Link: http://www.sitepoint.com/html5-is-dead-long-live-html/