Prototyping Early W3C HTML5 Specifications

Today we launched the HTML5 Labs Web site, a place where we prototype early and not yet fully stable drafts of specifications developed by the W3C and other standard organizations. 

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.

Microsoft's approach with Internet Explorer as outlined in a blog post by Dean Hachamovitch, the Corporate Vice President for Internet Explorer, is 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.

First Prototypes: WebSockets and IndexedDB

The first two prototypes we are delivering today are Web Sockets and IndexedDB.

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.

A Call to Action

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.

Many thanks,

Jean Paoli

GM: Interoperability Strategy

Comments

• Anonymous
  December 20, 2010
  Thank you for websockets to experiment with today. I will try it now. When is geolocation coming? What is next on roadmap

• Anonymous
  December 22, 2010
  "For developers, this means that they can write sites to Internet Explorer and be confident that it is based on stable HTML5..." Nobody is developing sites for (?) IE anymore. We develop them in Firefox, check that they work/look OK in Chrome/Safari (maybe even Opera) by testing for API support and by adding vendor prefixes and switching some declarations around. After that we boot up IE8/9 and try to fix any major issues preventing a release. If IE9/10 doesn't support File API, the IE users will have to use old file browse dialogs, while the rest of the users will get desktop drag and drop uploading with progress events for a much better experience. If IE9/10 doesn't support CSS-gradients we will serve an image to IE instead, which will take an extra HTTP-request (if we're not using CSS data-URI's or MHTML, which will add to the size of the IE-specific CSS) making the IE experience slower. If IE9/10 doesn't support the Geolocation API we'll use the less exact IP-detection or just let the IE-user select where he/she is, making the experience worse in IE. I could go on and on, but the point I'm trying to make is that in the end the users who want a better, faster and more beautiful experience will switch from IE to Firefox, Chrome, Safari or perhaps Opera. Merry xmas!

• Anonymous
  January 05, 2011
  Here is a showcase of the IndexedDB API for IE - blog.nparashuram.com/.../indexeddb-for-internet-explorer.html