As the technologies around HTML5 continue to develop, people need a better way to distinguish the more experimental parts of HTML5 from the parts ready for use in mainstream sites. The recent browser technology kerfuffle around WebSockets offers a clear example of the problem that developers and consumers will face again and again over support for emerging standards.
With many HTML5 technologies still under active development, our approach is to give developers better choices and avoid false dichotomies around standards support. The IE9 browser has site-ready HTML5 support that developers and consumers can depend on. We will also offer developers “HTML5 Labs” for more experimental technologies still under development. By clearly separating prototype implementations from mainstream browser product ones, we can avoid many negative consequences.
In the IE9 product, we’re delivering on the key parts of HTML5 that are site-ready. IE9 offers support for real-world web patterns that developers are using today as well as the HTML5 patterns we expect to become more mainstream. IE9 does this because we want to improve interoperability on the web by providing developers a consistent programming model through the same mark-up. The goal is supporting great new capabilities, ideally in a way that interoperates or will interoperate soon across browsers.
We will also offer prototype implementations for the more experimental or unfinished parts of HTML5 that some developers may want to try, but consumers can’t depend on yet. We will be explicit about the implementations that are more prototype than product. These prototypes are how we balance providing a product for millions of consumers while actively engaging in speculative technology discussions with developers and enthusiasts and avoid confusing either group. You can read more about that here.
In this post, we look at the pattern of putting unfinished technology into a product, the negative consequences of doing that, and our alternative approach for other HTML5 technologies that are still under construction today.
First, WebSockets are a good idea.
They are both a technology and a set of standards that are under construction. They’re often included as part of the HTML5 discussion. With WebSockets, browsers and sites can do some neat things that are otherwise very hard, very slow, or not possible. You can see videos of some scenarios enabled at http://www.websockets.org/ – a site not actually related to any of the organizations working on the standard, but from a company that has some product offerings in the space.
Implementing a technology while the blueprints that describe it are still changing significantly causes many problems. In this section, we’ll use the experience of WebSockets to illustrate common challenges of under construction technologies. Below, through the transparency of Mozilla’s process, you can read for yourself how several different problems played out.
This is a view into the difficult discussions and decisions around a technology under construction: guarantees that websites will break multiple times between today and when the technology is finished, the security risks to people using the technology, and the challenge of listening to a lot of contradictory feedback.
Let’s look at bug number 602028 in Bugzilla, Mozilla’s issue tracking system. For people less interested in these details, this is a good place to skip ahead to the next section.
This bug was first reported 5 October 2010. The bug suggests initially that “while the final WebSockets protocol is sorted out,” Firefox should do “prefixing.” One of the first comments in the bug immediately stakes a position (of disagreement), and calls out the compatibility issue that developers will face writing sites that work across browsers with this technology under construction:
We most certainly should not… Prefixing in Gecko doesn’t gain anybody anything… It only hurts us, because “Firefox doesn’t implement HTML5”. Comment 2
A subsequent comment cites the same facts – volatility and compatibility issues – as an argument in the other direction.
The reason that we want to prefix it is because we know, 100%, that it’s going to change. We also know that other browsers will update it as well. We don’t want it confused with… anything other than experimental and the best way to do that is prefix it as such.
The new version will not be compatible with existing implementations. Comment 7
Other comments go on to cite precedents for either course of action (here, and here), adding “WebSockets won’t exit demoware status for a few years.” That’s a powerful comment about the pace of technology adoption. Cynically, the discussion goes on that “the who’s-in-the-lead perception may trump all other considerations… We [Mozilla] are… constantly eating WebKit’s dust. I would lay a bet we’ll do it again here.”
A key point in the discussion is that developers “can be expected to expect their server’s [sic] will break as new versions of WebSockets are implemented in browsers.” A Google employee working on WebSockets goes on to add “the best strategy is to just keep breaking people.” A Mozilla person responds with his concern that this
assum[es] that the developers will have the perfect knowledge of everything that’s happening on the web, what the status is of various standards are and if things are going to change. Given my personal experience that’s a dangerous assumption. Comment 27
That’s when someone brings up the security issue, and another person makes the observation that it might not be worth “being able to check-off another ‘HTML 5 support’ box on the marketing slides.” Someone goes on to say what the standard should do and that they should follow it, to which someone else responds:
That would be great. Except that there is no standard yet, just a series of working drafts, with incompatible handshakes, and no plan… that doesn’t simply cause servers using older handshakes to barf on newer ones. Comment 73
The Negative Consequences
First, work on WebSockets continues today and Microsoft is part of that discussion. No one should interpret this recent news as the end of WebSockets.
One tech publication wrote that “the Web Sockets history illustrates some pitfalls of the style and pace of Web standards development,” and that “including support for a specification [that] wasn’t done” is just the latest wrinkle. The article’s headline describes “the risk of unfinished standards,” while another article describes “emerging Web standards like WebGL and WebSockets,” and a comment from a Mozilla leader here refers to “speculative features.”
WebSockets is just one of many, many unfinished, emerging, and speculative features. Rushing ahead with implementation while the blueprints are changing a lot creates dissatisfaction. This (warning: potentially NSFW) video dramatizes that developer dissatisfaction. That dissatisfaction is the result of supporting unfinished, emerging, and speculative features in the mainline product.
The question is how to balance the implementation of these under construction technologies (in order to resolve under construction issues) with the needs of developers (who don’t like re-writing their code over and over to get new capabilities) and the needs of consumers (who expect sites and browsers to just work). Today, iPhone and iPad 4.2 support WebSockets. Firefox and Opera have recently disabled their implementations because of (among other things) the security and compatibility concerns.
An Alternative Approach, because WebSockets are Not Alone
One alternative approach to these experimental features is being much more explicit about implementations that are more prototype than product. This is the approach Microsoft is taking. You can read more about it here. Through these prototypes we balance the objective of providing a product for millions of consumers and engaging in early speculative discussions with developers and enthusiasts, without confusing either group.
There are many other technologies under development today that are still under construction. Because they are not site-ready today and will not be ready, relevant, and real-world before we release the IE9 product, these emerging standards are susceptible to the same problems and negative consequences that WebSockets has faced. Some technologies are in transition and being reconciled with others (or potentially abandoned in favor of others). SMIL animations and SVG fonts, though they are used in the Acid 3 test, are on the way out in favor of CSS animations and WOFF. The Web SQL specification, for example, was formally taken off the Recommendation track at the most recent TPAC with the emergence of IndexedDB as a better path. IndexedDB is itself an emerging and unfinished standard, along with WebSockets, the File API and WebGL (as the Ars Technica article above points out).
There are many technologies that can easily play out the way WebSockets have. Developers and consumers are better off if these technologies are brought forward as explicit prototypes rather than in the product that so many people depend on. WebSockets and the IndexedDB web storage are the first prototypes in the new program. Some experimental CSS3 modules are potential candidates for prototypes, along with other technologies (e.g. the File API). This is a process we’re excited to work through with the community.
In developing IE9, we considered how different specifications are still evolving at different rates. IE9 supports technologies that, while not always finished, are developed enough to avoid the problems that WebSockets illustrate today.
In the IE9 product, developers can expect site-ready HTML5 so they can take advantage of the best of HTML5 that is ready and can still experiment with emerging HTML5 with HTML5 Labs. By keeping these separate, developers get what they need without the negative consequences of co-mingling very different things in the same browser.
IE9 offers support for the most relevant, real-world web patterns that developers are using today as well as the HTML5 patterns we expect to become more mainstream. By relevant and real-world, we mean the technologies with the broadest impact for browser users (e.g. CSS ahead of MathML). By support, we mean providing developers a consistent programming model that enables the same mark-up. The goal is supporting great new capabilities, ideally in a way that interoperates or will interoperate soon across browsers.
This approach (along with its supporting points, like test suites and “same markup” as a goal) has garnered strong support from developers. It’s also resulted in some surprising headlines over the last year, like “Only Microsoft gets web standards” according to “Mozilla man [who] blasts Apple and Google for HTML5 abuse,” from The Register.
In this context of unfinished technology, measuring how much HTML5 different browsers support through “benchmarks” does not make much sense. In particular, many of these tests (like Acid 3) include different partial collections of unfinished standards, while they exclude deep or broad assessments of the quality of the implementations. The key questions for tests are how appropriate is their scope, how accurate and rigorous are the individual tests, and how comprehensive is their coverage. The standards bodies involved in the process of developing the standards (like W3C and Ecma) are a great forum for the development of trustworthy, high-quality tests.
Professional website developers are busy. They write a code for a living and genuinely don’t have the spare time to wade through comments on all these under construction specifications and keep track of every build of every browser. With this approach, we make it easier to take advantage of the capabilities that are stable and ready for prime time. We remove much of the guess work for developers of working with a moving target. The result is more time for site developers to innovate and create better web experiences.
Back in March when we released the first platform preview of IE9, we were clear that we love HTML5 so much we want it to actually work. One aspect of that involves using the whole PC to run HTML with the best performance. Another aspect is working with community and standards bodies on test suites. Making sure that developers avoid the frustration of wasted time re-writing sites over and over as technologies change – and that consumers avoid frustration of sites that break easily – is just as important.