What is Microsoft’s approach to assure HTML5 et al stability when web developers are absolutely negative about that based on their previous experience?
Microsoft’s answer came crystal clearly two days ago in a blog post quoted below. But before coming to that let’s include here the whole closing section of that post because it is summarizing the Microsoft approach about HTML5 et al stability very well (emphasis is mine):
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.
In other words Microsoft’s approach is, as defined in the same day post Prototyping Early W3C HTML5 Specifications by Jean Paoli, GM, Interoperability Strategy:
… to implement standards as they become site-ready for broader adoption.
Writing Sites to IE Based on Stable HTML5
For developers, this means that they can write sites to Internet Explorer and be confident that it is based on stable HTML5 and will work in future browser upgrades. For users, it means that sites continue to work as they upgrade their browsers and they don’t get locked in to older browsers.
At the same time, Microsoft sees an important need in continuing to drive experimentation and testing of new specifications in the standards organizations. It is part of the process of ensuring that specifications are actually ready for real-world usage.
This new HTML5 Labs Web site is the place where our Interoperability Labs will publish prototype implementations of certain unstable and in-progress W3C, IETF, ECMA and other standards specifications still undergoing a lot of change. So, developers should expect that code and web pages based on these prototypes will have to be re-written as the specifications mature.
So please experiment with these prototypes and tell us and other working group participants whether the APIs are usable. We are making them available to help improve the final specifications.
Other implementers can use these prototypes to determine whether we have interpreted the specifications in the same way, and a larger audience can get a better sense of what potential will be unlocked when these specifications have stabilized into interoperable implemented standards.
Also, please participate in the appropriate standards bodies to help finalize the specifications.
HTML5, Site-Ready and Experimental [Dec 21] by Dean Hachamovitch, Corporate Vice President, Internet Explorer (emphasis is mine):
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 [ Prototyping Early W3C HTML5 Specifications [Dec 21] ].
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.
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.
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.
Introducing the WebSockets Prototype [Dec 21]
Prototyping Early W3C HTML5 Specifications [Dec 21] by Jean Paoli, GM, Interoperability Strategy:
These prototypes will help us have informed discussions with developer communities, and give implementation experience with the draft specifications that will generate feedback to improve the eventual standards. It also lets us give the community some visibility on those specifications we consider interesting from a scenario point of view, but which are still not at the stage where we can consider them ready for official product support.
WebSockets is a technology designed to simplify much of the complexity around bi-directional, full-duplex communications channels, over a single Transmission Control Protocol (TCP) socket. It can be implemented in web browsers, web servers as well as used by any client or server application. The WebSocket API is currently being standardized by the W3C and the WebSocket protocol is being standardized by the IETF.
For its part, IndexedDB is a developing W3C Web standard for the storage of large amounts of structured data in the browser, as well as for high performance searches on this data using indexes. IndexedDB can be used for browser implemented functions like bookmarks, as well as for web applications like email. IndexedDB also enables offline scenarios where the browser might be disconnected from the Internet or server.
We chose these two specifications primarily because they are potentially very useful but currently unstable. These are the two specifications we currently believe the community stands to benefit the most from, but both are in flux.
The details of the HyBi protocol underlying WebSockets are being hotly debated in IETF right now, and the IndexedDB spec will soon be updated to reflect decisions made at a recent W3C working group meeting.
Announcing HTML5 Labs [Dec 21]
As you hopefully know by now, despite the hype, HTML 5 is not a completed specification. In fact, back in 2008, the author of the specification, Ian Hickson, estimated HTML 5 wouldn’t be a Proposed Recommendation until 2022! Indeed, the W3C site shows there are still significant aspects of the HTML 5, CSS 3, DOM and other specifications being fleshed out – just take a look at the ‘warning’ in every W3C Working Draft: Implementors should be aware that this specification is not stable.
Waiting until 2022 for all i’s to be dotted and t’s to be crossed is obviously not an option though. It’s infeasible to expect a drop of all these technologies at one fell swoop, and there are certainly aspects of the HTML 5 and related specifications that are relatively solid today: canvas and and semantic tags, to name a few. These are the types of stable ‘standards’ you’ll continue to see implemented in the IE 9 beta and the continuing cycle of Platform Previews.
But what about those bleeding-edge features? The ones like WebSockets (currently an Editor’s draft) that Firefox 4 and Opera recently disabled due to security issues? Or features that other browsers are “implementing” with vendor-specific extensions and the such?
There’s clearly need for a balancing act between providing a dependable, solid browsing experience to millions of users and incorporating new features that haven’t been completely vetted in the wild. With his post today, Dean Hachamovitch, announces another facet of Microsoft’s strategy to walk this tightrope between responsible development and active adoption of emerging web standards.
HTML5 Labs currently offers two prototypes: WebSockets extension for IE and IndexedDB for IE. WebSockets is designed to enable “bi-directional, full-duplex communications” between a client and server via “a single Transmission Control Protocol (TCP) socket,” according to a blog post by Jean Paoli, Microsoft’s general manager of interoperability strategy. IndexedDB aims at enabling the storage of “large amounts of structured data in the browser,” accessible both online and offline.
Philippe Le Hegaret, interaction domain leader at the W3C, noted in October that some of the HTML 5 spec shouldn’t be used because of interoperability problems.
“The problem we’re facing right now is there is already a lot of excitement for HTML5, but it’s a little too early to deploy it because we’re running into interoperability issues,” Le Hegaret said at that time.
Microsoft, in rolling out its HTML5 Labs site, essentially agrees with Le Hegaret’s position, according to Paoli.
“We are in complete alignment between Philippe and Art; it’s more [about] the articulation,” Paoli said in a phone interview. “He [Philippe] actually wrote a blog after that explaining what he really meant. What we are saying is the same thing. We’re saying that every feature in HTML 5 — and there are many of them — every single one of them is not at the same level of stability.”
It could be as long as 12 more years before W3C Recommendation status is reached for the entire HTML 5 spec, but browser makers have already made parts of it practical to use through interoperability testing. Hachamovitch has described Microsoft’s position with HTML 5 as “write once, run anywhere.” If that goal is achieved, it will be a big change from the days when Web developers suffered with having to code for IE 6’s quirks, causing perpetual rewrites.
The HTML 5 spec is actually progressing, according to a comment by Giorgio Sardo, a Microsoft senior technical evangelist.
“HTML5 made lot of progress in recent months, [with] the HTML5 specification expected to go to Last Call (kind of feature complete) in the first 2-3 months of 2011,” Sardo wrote in a November blog post. “From there, the spec will move to Candidate Recommendation and there will be a call for implementers.”