“HTML5” is huge. Different specifications are at different status: First Public Working Draft, Working Draft, Candidate Recommendation, Proposed Recommendation, and lastly Recommendation.
As we stated many times before, it’s important to make it right.
Browser makers have a big responsibility with developers: it’s wrong to claim “standard support” for a specification that is still changing. Or, at least, they should make clear it is still a work in progress (for example, by using vendor prefix extensions).
Rushing the implementation of a specific feature and call it “done deal” is dangerous and in some circumstance can bring to unpleasant results. Today we’ve seen an example of this with an important specification: Web Sockets.
Web Sockets (W3C Specification)
Web Sockets enable Web applications to maintain bidirectional communications with server-side processes. The specification (from the WebApps WG) is currently in the “Working Draft” stage; there is also a dependency on the Web Sockets Protocol, discussed in the IETF hybi mailing list.
Chrome 4+ has been the first to implement it in a “final RTW build” at the end of 2009, followed by Safari 5.0.2. Instead Firefox was planning to support them in the version 4beta and Opera in version 11, but they never went in production (credits for monitoring its status before going live). IE doesn’t implement this spec in current build.
Over time the specification changed and each browser tried to adapt by releasing sequential implementation updates. Some developer even built “The Ultimate HTML5 Browser Support Test” based on specs like this that are still in Working Draft stage. A few users commented on IE Blog about IE being “the only browser” not supporting it yet.
On Nov 26th, Adam Barth shared the results of his experiments with IETF.
“The Upgrade-based handshake is vulnerable to attack in network configurations
involving transparent (or intercepting) proxies.”
In other words, the current protocol used by Web Sockets might be unsecure and unstable.
Based on this discovery, Firefox and Opera promptly did the right thing, announcing they would disable Web Sockets in future releases – until a solution is found. At the time I’m writing this post, I haven’t seen any announcement made by Google or Apple yet, although I’m confident they will follow soon (as Mozilla developers do).
In developer language, this is what I call a “breaking change”. Changing (or even worst, removing) support for a feature from a version to the next one – possibly breaking all applications built by developers based on the assumption that the feature (a supposedly “web standard”) would have been supported moving forward.
After today announcements, I wonder how many apps using Web Sockets will need to be brought offline, or “freezed” or “re-written” – at least until the spec get more solid and secure? Did these developers use browser feature detection, or they just assumed that any version after (for example) Chrome 4 will support that feature the same way?
What about those existing enterprise solutions, for example Kaazing, that rely on the assumption that “most browsers” already support Web Sockets? Will they just use the Flash-based layer (as they do for IE today) for any browser?
Personally I like Web Sockets. I’m looking forward to seeing them available in all browsers. But I also do care about consistent implementations, that work the same (interoperable, secure, stable) way across any browser – over time. I don’t want to write some code today, falling in the “(non) Web Standard trap”, and then have to re-write my code in 1 year from now because that particular implementation wasn’t exactly ready for prime time yet and has been removed or changed.
I don’t want to see the “IE6 phenomenon” happening again to “Chrome4” or others. Do you?
Someone today was so disappointed that he created a short humoristic video…
Time to go back to W3C and IETF to discuss what went wrong and look at what we can do to accelerate the progress of this (and other) specs...