HTML5, Site-Ready and Experimental

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.

The WebSockets

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).

Site-ready also looks at the larger context of developer needs today and tomorrow and the viable alternatives as well as the state of the standards process. For example, CSS3 is an enormous set of technologies. IE9 already implements many CSS3 modules that are site-ready. Several other CSS modules (like CSS3 Gradients) are still emerging and unfinished. Other modules have perfectly fine interoperable alternatives, like using script in place of CSS3 Transitions and CSS3 Animations. For other technologies, like web workers, other considerations apply as well. Web workers introduce complex multi-threaded programming concepts to JavaScript, and require extensive prototyping (just like WebSockets) to fully explore the impact on developers and the broader web programming model.

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.

Looking Ahead

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.

I think many people (JM…) just didn't understand the Microsoft strategy. You'll not see Geolocation, Transitions, FlexBoxes and WebWorkers in IE9 because the next version of IE9 will be the release candidate. Microsoft will not introduce a new, potentially buggy, feature in a non-beta builds (or at least not something as big as those complex features), because nobody will be able to test it in time for RTM and we'll find a lot of bugs after IE9 come out, which is not what the IE Team want.

IE10, on the contrary, will be another story, which will probably benefits from those new features like IndexedDB and WebWorkers.

Chrome is a perpetual beta version. My website works very well in Chrome some day, it has rendering issues three days later. Then everything is fine a week after that. It's simply not serious. IE is intended for enterprises. When something is added, it should work. Microsoft did the mistake of adding bad stuff to IE (in v5/6) to rivalize NetScape and they've paid the consequences. Now, they just don't want that situation anymore, which is good for us, developers.

@FremyCompany: I don't think that's the point as far as geolocation is concerned, as it's already been implemented for WP7, and I doubt it'd be costly to port it over. It's just that it's not a feature that is seen as important for non-mobile machines.

As web developers this shouldn't be any problem. We will continue to detect features and degrade for slower moving browsers. Users will continue to transition to browsers that deliver a better experience.

@JM: Yeah, you're probably right they should clearly say what's in line for RTM, and not only give us expectations. I think they prefer to talk about what they did than about what they didn't 😀 The following tweet make it clear, I think :

— Anne van Kesteren :

— Microsoft PR-speak to English: "What we implemented is awesome. What we did not implement in time is obviously not ready."

I must agree it's quite easy for MS to say "yeah, it's not ready, and it's why we didn't implement it" but we all known some things like HTML5 Forms are stable and should be implemented. Same for XPath and document.evaluate. Naturally, and it's logical, each company has its own marketing strategy. MS has chosen to say what he didn't implement is not ready. For the great majority of webdev and for company managers it will sound true, as an high level of knowledge is needed to find out which is already ready to implement and what's not, and because what's not implemented in IE is not widely used on the web. This "readiness" argument masks the (few) issues they just didn't had the time to fix. Why not. It's logical to make choices, you simply can't do everything. Chrome devlopers also said "using the GPU is not needed" when Microsoft first announced his intention to accelerate the browser with the GPU. Many Chrome fans agreed, at that time. Some still do. It's only strategical.

Did you miss the whole discussion in the article about vendor prefixes? It's basically like painting a huge sign in the browser for hackers. Look over here, this is where the unstable and potentially exploitable stuff is. Not to mention developers use it anyway and then it has to be maintaned in the browser indefinitely. If the prototype code ships out-of-band, then there's no confusion.

How about supporting HTML5 in IE9 instead of just updating the CSS engine and calling that HTML5? From what I've seen of the latest IE9 beta there is very little relevant additions for building real-world web applications.

Its wonderful that you can program games using HTML and CSS in IE9 now, but I build intranet applications for government and other corporations. They really don't care about a browser that can draw swimming fish really fast, and neither do I. It might make pretty things, but it currently isn't the "site-ready HTML5 so [we] can take advantage of the best of HTML5 that is ready" at all, is it?

What happened with Websockets is disappointing – even upsetting; but there is a lot more to HTML5 that the IE9 beta hasn't brought us that other browsers are. According to http://html5test.com/ The latest IE9 beta I have gets 96+5 points out of 300. Even Firefox 3 gets better scores. According to the test IE9 doesn't support the new HTML5 tokenizer, treebuilder; elements like section, nav, article, aside; none of the new form input elements like autofocus, or placeholder and validation attributes like required or pattern. These are all really important features for application developers and they are mostly supported by the latest Chrome, Firefox 4 beta and Opera builds.

From what I can tell, the biggest thing we can expect from IE9 is hardware acceleration of CSS and rendering. This is solving a problem that AFAIK nobody has. This is not HTML5. This is not HTML5 for enterprises. Some people might be making games in HTML5 right now, but this isn't the typical case. We can do that in Flash and Silverlight if we need to – and until more browsers support HTML5 it is probably a better idea to do it that way.

I'm encouraged that Microsoft is work towards HTML5 support, but calling CSS3 features "HTML5" is not a good start. I'm looking forward to Microsoft supporting HTML5 soon, but I've been disappointed in what I've seen in IE9 so far.

Since these standards are evolving rapidly, there are sure to be parts that finally get nailed down between IE releases (which seem to occur every 2-3 years). Will Microsoft add these in, either in a patch or a minor point upgrade? Chrome may not be "serious" with all the releases they do, but Firefox is, and their minor point release cycle is a fair bit tighter (every year or so). I'd rather not wait 3-4 years from now before we see Web Sockets in IE, especially if the standard is nailed down a year from now.

"Other modules have perfectly fine interoperable alternatives, like using script in place of CSS3 Transitions and CSS3 Animations."

Argh. Second what Lance said — lack of transitions and animations is going to be a pain in IE. Writing script instead of using CSS is not "perfectly fine" for a busy developer. We'll get uglier sites, not better implementations.

It's fine if our sites don't animate on ancient computers with XP/IE6, but it'd be great if the de-facto-standard transition syntax WebKit, Mozilla, and Opera support worked on the latest versions of all major browsers. There will be corner cases and that's fine. Transitions are not WebSockets — at this point you're not going to wind up with an implementation that's so different from the rest it's unusable, given three implementations to compare with and a non-final standard.

It's doubly frustrating since the lack of animations in IE9 will mean animations won't be usable for *years*. Given that Microsoft seems to both have longer release cycles and push upgrades less hard than, say, Google (tell me it isn't so), we're going to be writing animation code for IE9 well after Chrome has flying cars (CSS4 declarative flying cars, even).

I think the flipside of the argument Dean's making is that developers are surprisingly skilled when it comes to dealing with all but the worst incompatibilities. Also, fielding technologies early gets a kind of testing that lots of smart engineers at browser vendors can't provide on their own, and it allows for early adoption, either by big sites with graceful degradation — like how a major Webmail service uses HTML5 offline features in a major mobile browser — or by folks who are figuring out what these technologies can do and helping push Web development forward *that* way — think of a competitor's "experiments" site, or some of the awesome stuff jQuery dude John Resig has put together. "Demoware" can actually be quite useful.

It doesn't mean there shouldn't be due diligence to make sure the first released implementation doesn't suck, and to avoid situations like WebSockets. I do think prefixing's a good idea. Still, I'd rather keep living in a Web with some random incompatibilities and fast advancement than a perfectly compatible, slower-moving one.

If Microsoft wants to avoid saddling the Web with backwards-compatibility work, give us a faster release cycle and try to reduce the number of legacy users — and, pragmatically, get IE6 gone ASAP. Not that it's at all likely, but a backport of the new rendering engine to XP, like a competitor's "frame" plugin but by Microsoft and pushed out as an update, would mean a lot of happy developers. 😉

I wonder what is IE team's stance on the new input elements (e-mail, date, etc.). Are they good enough to be supported? I see them as the best part of HTML5 because they save a lot of work and fail gracefully (become textboxes) in older browsers.

I didn't miss it, I just rather have the choice as a developer to use it at my own risk then not have the ability at all

and having to resort to even more insecure stuff like Flash. If a feature becomes insecure and it can't be fixed they

can just disable or remove it, because we used it at our own risk.

As soon as any of the prefixed features becomes a standard and the future IE browser will support it we will be updating our web applications anyway and push our users to upgrade there browsers to the latest IE version, or they will be missing out on features.

But if IE9 won't even support the basic file attribute "multiple" we will have to resort to recommending Google Chrome Frame to our users, because we no longer wanna put Flash as a requirement for something so obvious as basic multi file selection for uploading (more faith in Google then Adobe).

I think IE9 is ready for the traditional Html Websites, but I am a web developer, and there is nothing traditional in Web Applications, I used WPF (biiiiiig mistake) in a project, and I wished they did like Google Chrome (update it and improved its performance every 6 weeks), but this never happened and we still struggle with its performance.

Updating a browser every 6 weeks is hard, making it faster and adding more features is not easy, but Google is doing it anyway, and they make it look soooooooo simple.

Looking at natural selection, the future is for the faster, the smarter, the better, … 🙂

One more thing, I am still not sure how will Microsoft compete with Google Chrome, IE 9 will be released, Google Chrome has much more API, much faster (with very few exceptions), and will surpass IE9 in few weeks after its release.

On the other side, Microsoft will go in hibernation, as we are used too with every other Microsoft product, and then?

What Google does is not really preferable over what Microsoft does. They update the browser frame (at least I think they do…) and the V8 script engine every six weeks.

They don't update one bit of WebKit though, which is the most buggy and incorrect collection of as many features as possible one engine can be. If Google would at least put some engineers on CSS and script compatibility, WebKit could really be a great engine.

MS on the other hand is too conservative. The long release cycle may have made sense when serious work was necessary (i.e. CSS 2.1 compliance, maybe even SVG), but a modern browser should be updated at least once a year.

The further downside is, that even thoug it currently takes about 2 years for a new version of IE to be released, Microsoft is not working out the details.

I can completely udnerstand that one would want to be conservative about implementing new features. But I can not understand, that minor and middle sized issues are not fixed even if they're an apparent spec violation (or an apparent bug that makes just no sense).

So unfortunately, at the moment, MS clombines the disadvantages of both methods…

I believed Microsoft for more than 15 years, but the last 5 years where when the company went down on every direction, I know that users don’t care about API, but I do. In order to run applications written by us, you must have Google Chrome, simple, the same as you need Java to run Java or .NET to run .NET.

Google is saying that the browser will become faster and better once every 6 weeks, I don’t care if they get it faster even by .0001%, at least there is someone who is doing everything they can to make developer life better.

Search the internet for the negative reaction about VS.NET 2010 service pack 1, and how slow WPF is; so much advertisement when Microsoft released it 4 or 5 years ago, 3d accelerated, good graphics engine, and it turned to be the slowest technology of all time.

Yes, I use Google, they did not mislead me with false advertisement yet.

I don't know. Our project breaks with every Chrome release. It breaks with every IE release too but at least it is not every six weeks. BTW I am pretty happy with VS 2010 but I use it to develop web apps so I do not know about WPF pains.

So, folks, basically Microsoft is saying this: because some lazy web developers don't want to upgrade their webapps when any API changes, they (Microsoft) will not support any of these innovative web technologies.

I applaud Microsoft for focusing on improving the lives of all lazy web developers!

When is a detailed specification of the product version of IE9 open to the public?

First of all, please clarify the one that it is possible to use it and the one that it is not possible to use it.

I want you to offer the list of the tab of HTML to be able to guarantee operation with IE9 and the list of the attribute that can be used in those tabs. Maybe, I think that it becomes the subset of the draft of HTML5.

If you add just one html5 form feature in IE9, make it the placeholder text. Should be extremely easy to add and it replaced the current need for javascript to do such a simple task.

But anyway, I do like how IE9 is handling standards for the most part. Obviously I would like html5 form stuff, but just adding things that really work will keep things simpler in the future. Also, I hope this post will get all the people begging for websockets to be quiet for a while =p

@Luis so your definition of "lazy" is developers who have actual work to do instead of update their working code every six weeks. Let alone that small companies may not have the budget to pay for constant upgrades to their web apps.

@Stilgar, then just write a wpf/silverlight/win32 app, AND FREAKING LEAVE THE WEB ALONE!

Oh, i see, you kinda like this "web" idea. Nice isn't it? BUT writing an IE6/7/8 app is not writing a web app. Web apps are (currently) hard to make. If you don't like this fact learn something else. [May i suggest FrontPage 2003, it's very user friendly :-), or flower arrangement]

Repeat:

Silverlight != The web(tm)

App tailored to IE6/7/8 != the web

BTW, I do believe that Microsoft will fully open (patents and all) Silverlight some day, maybe when it's too late.

What's clearly appearing when reading the comments is that the current release cycle of IE (two years or more) is not suitable to web anymore at this time. The IE Team will need to provide more updates in the future (one every 8/10 months seems reasonable). A good solution would be to have a "pre-IE10" engine included in IE9.1 that would evolve with time, while the IE9 engine would stay the same. The pre-IE10 engine would only be triggered by pages having X-UA-Compatible: IE=edge (by default) or IE>9. Other pages could still use the RTM 9.0 shipping IE engine by specifying IE=9.

While I know it will not exists in IE9, this kind of feature is nice to have for IE9.* / IE10, because enterprises can release for IE9 and be sure the new updates won't break their internal website, but real websites can take advantage of more regular updates.

I think what this shows, and is echoed perhaps unintenionally by many of the commentors, is that Microsoft has far more experience in developing a solid, stable and long term platform for developers than anyone else on the planet. They've clearly learnt the mistakes of rushing implementations through, of trying for short term gain rather than long term benefit and are clearly bringing that experience to HTML5 at long last. I do hope, however, that we will see many of these more experimental, in development features in something like the platform previews, it'd be a great way to help iron out many of the issues with emerging technologies.

"In order to run applications written by us, you must have Google Chrome, simple, the same as you need Java to run Java or .NET to run .NET."

This is called vendor lock-in. You are just replacing "MS-standards" like VML or something with "Google-standards", which is what WebGL, WebSockets and WebWorkers basically are. But hey, Chrome **IS** HTML5, isn't it? Maybe, but to me definitely not as long as Google won't fix WebKits percentage-bugs.

I think, people just begin to understand the more complex & clean approach MS is taking on W3C-standards. Writing a comprehensive test-suite is far more work than it sounds, but without it, the underlying standard is pretty much unenforcable. It is far more work than tweeking a bit of performance every six weeks or introducing "standards", which are mainly a Google-brainchild itself.

As christmas eve is nearing, I have wishes:

First, CSS3- or HTML5-features should get to Candidate Recommendation as quick as possible, but as clean and verified as necessary. I hope, MS and Google will be drivers to get things done in 2011. The process must be streamlined. Plus there should be a timelimit: if a working draft remains in this state longer than two years, than it should be dropped altogether.

The second thing I wish is, that every technology should be checked not only against it's technological dimension, but also it's application. GeoLocation f.e. is a thing I look at very critically. How easy will it be for Facebook to track down users, if any browser has a comprehensive GL-API?

Third, there is the broader thing of companies inroducing standards at the location most convenient to them, not at the most logical location. Why is WebSockets an HTML-feature? It's HTTP. WebWorkers is basically a JavaScript-feature, but it is in the HTML-standard.

And last, MS should simply keep those Previews alive, even after IE9 has shipped. If a HTML5- or CSS3-feature gets fixed, it can be introduced in the Previews. And I really see no reason why ADDITIONAL capabilities cannot be introduced by Windows Update. I know, MS is reluctant of adding features outside the release cycles for communication purposes (read: PR). But here is no problem, since the audience are web developers fit for keeping themselves up-to-date. If you don't, it will basically defeat the purpose of PR.

In fact I don't like the web idea and I do prefer WPF/Silverlight/Whatever but there is a problem… my employer pays me to create web apps because customers want them (often not realising they would be better with thick clients). For the record these same customers want us to support IE6/7/8 so I guess I've already "FREAKING LEFT THE WEB ALONE".

But web developers aren't the only people who matter. Whilst they might want everyone to get a new browser every six months, that's just not practical in reality and longer, more considered release cycles are vastly preferable. The 18-month to 2 year cycle is probably the best compromise between the needs of everyone.

This is a good article written on Microsoft's HTML5 strategy and gives a good idea as to when we can expect the IE9 final release: http://bit.ly/i3nAFb

I should admit I am a .NET developer working primarily with Silverlight and Business Intelligence, but I am very open to and looking forward to using HTML5 where it is applicable (contrary to popular belief / CIO headlines, the two technologies can coexist) … bottom line is that although Microsoft may have screwed up their HTML5 strategy, after consulting my best friend as to what technology to use for a major financial group in Manhattan, we decided Silverlight was the only acceptable tool to use. HTML5 is not finished yet! It won't be finished until 2012! I consider myself an early adopter, but there's a difference between adopting / learning and actually applying something at an enterprise level. The development tools, AFAIK, are not up to acceptable standards. Given the change management cycle can take some time at many companies, it can be frustrating that HTML5 support will only be supported by IE9. At this point, I would suggest doing your beta testing for HTML5 by setting your default browser to something like Chrome then switch your default browser to IE for other applications such as ASP .NET. I tried IE9 and ran into too many issues with pre-existing applications. You can, however, use earlier versions of IE. I can help you there thanks to this article from the MandoGroup 🙂 http://bit.ly/hyi576

@ Stilgar – I agree, if anything I see those talks between Adobe and Microsoft (you know..the ones that suddenly went silent), as starting to reveal themselves through new computer sales – anyone notice a bunch of new computers are shipping with Silverlight pre-installed with a Silverlight based Adobe PDF reader? — seems to indicate something's brewing

@GT – Don't forget that the past 5 years of supposed failures (I would say there have been losses and victories – I wouldn't look it at as being so black and white….but I digress)….so those past 5 years have also included the introduction of Windows XP based tablet computers, Windows Mobile helped bring the concept of smart phones into a reality…Microsoft has led a period of innovation and a lot of it failed, but Microsoft set market trends. Others improved upon these technologies, Google was introduced as a new player, Apple still has their niche "cultural" market they've had a capture on since 2007 and HP recently went off in their own direction with WebOS. Where Apple and Google are lacking (we use Google Apps at the moment, but not for long…too many issues), I'm fairly certain Microsoft will soon take the lead – the business world – from PC to Tablets to WP7 phones – the integration capabilities and lowered costs by keeping everything on integrated platforms – Apple and Google will not be able to compete in that market. Assuming Microsoft acquired Moonlight, that will allow business users to use Linux based hosting for some .NET solutions even further lowering costs. The common argument that Windows 7 is incompatible with Tablets is an invalid point…just look at the ExoPC Slate for an example as to why I say this.

I respect Google (especially being a machine-learning geek, their page-rank algorithm is very interesting), but I'm not going to develop specifically for them. I will learn HTML5 for increased cross platform compatibility, but I'm in no rush.

"I don't know. Our project breaks with every Chrome release. It breaks with every IE release too but at least it is not every six weeks. BTW I am pretty happy with VS 2010 but I use it to develop web apps so I do not know about WPF pains."

I am not sure what your using that it breaks every release, care to elaborate?

We have been advising our users to use Google Chrome and or Safari / FireFox, as a last resort we also support IE8 (IE6 and IE7 are blocked).

Our web applications are fully Javascript driven and we haven't seen a single problem occurring due to a browser update with our application based on when we started recommending Chrome (back then it was version 4) to Chrome 8 and Chrome 10 (dev channels).

I am not saying Chrome is perfect (there are still some anoying bugs), but atleast it gives our users a really good / fast experience working with our web applications,

I am not sure because I am not the one fixing it but I often notice functionality that either breaks or misbehaves due to new versions of Chrome. Stuff breaks in both third party libs and in our own js code. In FremyCompany's comment in the beginning of the thread it seems like he has the same problem.

2.) IETester – works great until you need to test popup interaction and then it fails – thus a NO-GO

3.) Virtual PC with timebombed images of IE6, IE7, IE8 – works ok, but the 12Gigs of HD space needed is frustrating when each full image of Windows dies 4 times a year, running a full Windows image is slow and you have to beg for updates because the releases are not co-ordinated and announced well at all – thus its a NO-GO

4.) IE Super Preview – Last I checked this did not allow full testing of IE user interaction, JavaScript DOM changes, popups etc. – thus its a NO-GO

5.) Multiple PC's to run multiple versions of windows and IE. With all the hardware, software, and physical space needed – its a NO-GO

6.) Spoon.net IEs – They work, they work just like local native apps once running, and there's no hacking of my real local IE install. – the **ONLY** problem with these IE's is that Microsoft shut them down

Please understand that we (developers) just want something that works. Testing in multiple versions of IE is a pain to begin with and with IE9 on the horizon it is only getting worse.

I'm not sure where the issue stands with Spoon, but I would really like a solution worked out fast.

Wow … this seems to miss the point. IE, FireFox, Opera, Chrome and Safri should support the same stuff. Standards are a feature list with guidelines. If the Standard changes …. version the feature. Remember MS XML 1, 2, 3, 4, 5, etc. We are not talking about issues for users, we are talking about developers. We get versions and changes. Do it now, if it changes, add a new version number. Really ….. where are the smart people a MS.

So Today's Microsoft "cop-out " phrase is "site-ready". Any technology/spec that MSFT doesn't want to implement or is behind on implementing is therefore now not "site-ready".

What is really sad is that in order for many of these specs to see the "recommendation" status, there must be actual reference implementations by 2 or more of the "big" browsers.. and often IE is the browser "Holding back the Web" [TM]

Since you've highlighted the features that likely won't see action in the IE9 RTM, lets at least discuss the items that are: "site-ready" that are just waiting for IE to finally catch up on.

1.) Geolocation – Seriously!… this isn't a hard API to implement and yet provides major possibilities to developers that they currently have access to on EVERY OTHER BROWSER! best of all, 100% of this does not affect DOM rendering etc. so it can be updated/improved on-the-fly at any time, in any release/patch – therefore there is absolutely no reason why IE9 should not support this

2.) innerHTML – Developers have complained about this for years and Microsoft developers themselves have indicated that the existing poor support was due to a buggy implementation. Its been over a DECADE since MSFT released this buggy implementation – where's the fix?! – Since innerHTML is now part of the HTML5 specification – IE9 must support it completely and properly if MSFT expects developers to continue supporting IE, and especially if MSFT has any intentions of claiming that "IE9 is HTML5 ready" – because currently that statement is a load of bunk!

3.) localStorage – I know this supposedly worked in IE8 – but even in IE9 (latest preview) I still find that my tests indicate I can't develop in IE because it refuses to understand/use my local drive/localhost/127.0.0.1/192.168.x.x – if there is a special setting we need to set to make this work – please advise

4.) video/audio – Developers need a common, free AND open format to deliver content. IE9 **NEEDS** to support WebM AND OGG for video, and MP3, OGG for audio. Please stop hiding behind DRM shackles etc. and just release a browser that works!!! If HTML5 audio/video is unable to gain traction in the market it will be 100% based on IE9 not supporting the correct formats.

On a side note someone above mentioned that WP7 (Windows Phone 7) actually does support Geolocation in IE (whatever version that is) – if this is the case – it looks like the technology is already there, hurry up and port it! If however this statement is false and WP7 does not support Geolocation – what on earth was MSFT thinking releasing a mobile smart phone with a browser that doesn't support Geolocation?!?!?! it would have made much more sense to release it with a WebKit based browser.

Can you (Microsoft) please clarify the state/release of Geolocation on the Windows Phone 7 and IE9 RTM.

I am sure you have sources inside Microsoft, that have told you exclusively about technology that Microsoft "…doesn't want to implement or is behind on implementing is therefore now not "site-ready"…."

That is amusing! (I am polite in this one, other descriptions also come in mind)

I think we are forgetting a major difference between Google and Microsoft, Google is creating a full application environment inside Google Chrome, Microsoft is just writing a new release of a web browser and it has independent application environments one of them is .NET.

I am pro innovation and against standards, and I was with Internet Explorer all the way until Chrome, after all, we all know that the most popular browser is the one who will define the standards.

The Chrome application environment evolves every 6 weeks, and now getting way faster than .NET or Java or any other browser technology including Silverlight, V8 interaction with the UI is now hundreds of times faster than C# and Java with very large forms.

Put a large amount of HTML in a page, interact with it using JavaScript, and try the same with Silverlight or WPF, or any other UI technology, none of them can match Chrome (with a few 3d exceptions in IE9), and Chrome dev is catching up with that pretty quick.

Microsoft will release IE in a few weeks or months maybe as they do with other software, but Chrome will continue evolving their browser/ app environment and make it better, faster, and more features every 6 weeks, I don’t know how can anyone compete with that.

"@Stefan van Zanden you are assuming that Flash will not introduce any new features while browsers get its old features. Funny thing but new features in HTML historically come from plugins."

I am not assuming that… but the fact is that with HTML5 and the coming HTML6 standards it will close the gab feature wise, so Flash currently still is somewhat ahead which it might keep up for a year or 2 but the HTML standards are catching up on Flash pretty fast, so if Adobe would introduce a new feature in Flash and if it is a great feature it will probably end up in the standards after the release in Flash (they could call Flash an experimental sandbox then :-)).

However when I look at Adobe building a tool for converting Flash to HTML5, I see that they are embracing these standards and will also move towards these new standards.

So when there is enough browser support, they might just decide to not built new features into Flash anymore and instead propose a new spec to the W3C so it can be build in all browsers natively. But if I would make a prediction it would be that Adobe decides that in a year or 3-4 when the most used IE browser is IE10 followed by IE9, that IE6 and IE7 are gone and that IE8 will become the next IE6.

@Stefan van Zanden being a technology controlled by a single company with a single team creating the implementations Flash (and SL for that matter) is in position to introduce and deploy new features much faster than the HTML spec which moves like a glacier. The only theoretical way that HTML can catch up with Flash (or SL) is if Adobe (or MS) stops investment in it which I admit is a possibility especially if Steve Jobs takes over the world.

"@Stefan van Zanden being a technology controlled by a single company with a single team creating the implementations Flash (and SL for that matter) is in position to introduce and deploy new features much faster than the HTML spec which moves like a glacier."

I agree on this part, only there comes a time where it will be hard to think of new useful features and HTML standards can catch up :-).

"The only theoretical way that HTML can catch up with Flash (or SL) is if Adobe (or MS) stops investment in it which I admit is a possibility especially if Steve Jobs takes over the world."

Which they might do when the HTML standards have so much comparing features that it wouldn't make sense for them to keep supporting Flash as a platform (money),

and developers stop using it because there is a better environment containing the features they need.

Lol.. I think Steve has a long way ahead of him to try that, with a pretty low Market share (comparing to Windows that is) on Desktops and the fastly emerging Android OS on the mobile systems.

But this is getting way offtopic…, all I ask is support for <input type="file" multiple="multiple" />, because that would mean no need for Google Chrome Frame or Flash for our Webapplications, and placeholder as an attribute for input fields 🙂

Remember how much developers hated IE for lacking rounded corners? Multiply that by 10 for how much we'll hate ie9 for launching without css gradients. Gradients are the most useful feature ever. If you really want to help developers you'd hijack the CSS Gradient discussion and force them to pick a way of doing them so you can launch with the feature.

The web is evolving at a rapid pace. By using, testing, reporting bugs and pushing half baked API's to their limit we will help moving the web experience forward for the rest. I'd hate to think what would happen to our industry if we kept waiting for IE to implement a feature before using it.

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 pre-upload thumbnails and progress events for a way 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 or using -ms-filter: "progid:DXImageTransform.Microsoft.gradient() if we don't need opacity) 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 more cumbersome 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. Some won't. They can keep on using the service at a more basic level.

@GT – I agree that Chrome is a better browser at the moment, but I don't see that as a justification for much else….not just yet, at least. Microsoft is really doing a poor job at bringing IE8 up to speed (see for yourself by running this HTML5 test site on IE8 then on Chrome: http://bit.ly/g8DaIe) …maybe they should have a Silverlight based browser so it's easier to roll out updates lol

@Banned in Boston – IMHO, I would suggest taking the wait and see approach on moving to Flex. Remember those talks between Microsoft and Adobe a few weeks back…well that went silent, but new computer models seem to be doing some talking – check out the included software on this new computer (namely: Microsoft® Silverlight Acrobat® Reader) – http://bit.ly/evbQ9k

Also some interesting news related to tablets and a rumored Windows 7 OS aimed at tablets and expected to show up at CES which is right around the corner: (Tablets) http://bit.ly/dQkMXc (Windows 7 OS) bit.ly/gQAN2R

Cool thing about bit.ly besides the analytics, you can add .qrcode to any of the extensions: http://bit.ly/gQAN2R.qrcode –> Microsoft's going to have to come up with an answer to that

"WebGL will likely never make IE as it is not a W3C webstandard but some private standaard created by competitors to promote OpenGL.

When W3C publishes a new 3D canvas or 3D SVG standaard Microsoft will support that in IE"

WebGL is as much as standard as anything the W3C creates, both are made up of primarily the same companies including Mozilla, Google, Apple, and Opera. Only one lacking is, of course, Microsoft, because supporting standards is great when it's convenient for you, but when they compete directly with one of your technology it's a no-no.

And in all actuality there's no reason WebGL in IE9 can't be hooked up to D3D, it's what Firefox is doing by using ANGLE.

will IE9's implementations of various DOM methods be fixed to follow the standard specifications? There are many methods that were implemented wrong in IE5.x/IE6 that have still not been fixed. Since IE9 will be the first decent release of IE in terms of being a browser that actually meets some specs and has half-decent performance it would be a tragic, epic failure if IE was still to not have fixed some of the most basic JS methods.

will IE9's implementations of various DOM methods be fixed to follow the standard specifications? There are many methods that were implemented wrong in IE5.x/IE6 that have still not been fixed. Since IE9 will be the first decent release of IE in terms of being a browser that actually meets some specs and has half-decent performance it would be a tragic, epic failure if IE was still to not have fixed some of the most basic JS methods. http://www.torrenzz.ru