HTML5, Native: Third IE9 Platform Preview Available for Developers

As developers experiment and begin the transition from writing today’s websites to building HTML5 applications, they will test the limits of browsers. For example, the huge difference between hardware accelerated HTML5 video and plain HTML5 video support in a browser was clear in the demo we showed at MIX.

Because some browsers run on many different operating systems, there can be a tendency to use a “least common denominator” approach to implementing HTML5. By using more of the underlying operating system, and taking advantage of the power of the whole PC, IE9 enables developers to do more with HTML5. Running through Windows, instead of just on Windows, makes a big difference; the web runs more like a native application. This is consistent with our approach of architecting HTML5 support in, from the ground up, rather than just grafting in some HTML5 features.

The third Platform Preview of Internet Explorer 9, available now, continues the deep work around hardware acceleration to enable the same standards-based markup to run faster. This is the latest installment of the rhythm we started in March, delivering platform preview releases approximately every eight weeks and listening to developers. You’ll see more performance, same markup, and hardware accelerated HTML5.

This video of same markup running in IE9 and other browsers shows what hardware acceleration means for the new, graphically rich and interactive HTML5 websites to come from developers:

Note this video uses the HTML5 video tag (with the H.264 codec) if your browser supports it, and falls back to other methods otherwise. It’s a good example of same markup in action.

Performance through the power of the whole PC

Today, people expect less from a website than they do from native applications in terms of power, richness, responsiveness, and interactivity. With the third platform preview, we continue to deliver on the promise of a fully hardware accelerated browser where all of the support for text, graphics, and media uses the underlying hardware through Windows, making the full power of the PC available for the Web. Using the power of the whole PC shatters the previous constraints that limited websites.

JavaScript is one component of browser performance, and Webkit Sunspider is one measure of script performance. The latest platform preview shows how IE9’s JavaScript engine continues to get faster. Here’s the chart:

You see the progress with this zoomed-in chart, showing just the IE9 platform previews and the pre-release versions of other browsers:

Looking at the differences between the script engines’ performance, you see the performance gaps between the fastest script engines are now less than 50 milliseconds – and that’s executing several million script instructions during the benchmark test. This difference is already under any human perception threshold, and we’re not done yet.

Many sites spend lots of time in subsystems other than JavaScript. If browser performance were entirely attributable to JavaScript, the performance on the test drive site samples would look like the Webkit Sunspider graph; that’s not the case. You can expect that we will continue to focus on real-world performance and not optimize for any specific benchmark.

Introducing hardware accelerated canvas, video and audio

With the third platform preview, we introduce support for the HTML5 Canvas element. As you know our approach for standards support is informed both by developer feedback and real word usage patterns today, along with where we see the web heading. Many web developers have asked us to support this part of HTML5 and we definitely took this feedback into account as we prioritized our work.

Like all of the graphics in IE9, canvas is hardware accelerated through Windows and the GPU. Hardware accelerated canvas support in IE9 illustrates the power of native HTML5 in a browser. We’ve rebuilt the browser to use the power of your whole PC to browse the web. These extensive changes to IE9 mean websites can now take advantage of all the hardware innovation in the PC industry.

Try the Asteroid Belt sample and Fish Tank sample on the test drive site to see hardware accelerated Canvas in action. Together with Amazon, we built a book shelf sample showing the potential for bringing the richness of hardware accelerated canvas into an interactive e-commerce experience.

Similarly, we partnered with the Internet Movie Database (IMDB) to build the Video Panorama sample to demonstrate the possibilities for bringing hardware accelerated HTML5 Video and graphics interactivity together to create new applications and experiences. Our focus is on delivering a complete, highly interoperable implementation of canvas, video, and audio that makes the most of the full power of the PC.

To help you better understand how these samples work, we created videos that provide a look “under the hood” for Fish Tank, Amazon Shelf, and Video Panorama. As the browser uses more of the hardware, your experience depends on the hardware you have, just as it always has. With hardware accelerated graphics, the graphics card and driver combination play a significant role in how you experience the various examples and benchmarks.

The PC hardware ecosystem has made huge advances over the last few years. Today’s GPUs provide up to 10 times the computing power of CPUs, a clear trend in GPU processing power compared to CPU over recent years. Given how important the web is, our focus is making that power available to web developers. With IE9 developers can run the same, W3C standards-based markup as in other browsers – just faster, taking advantage of the underlying hardware. The result of using the power of the whole PC to browse is a new class of web application without many of the limits on today’s sites.

The first two platform previews demonstrated hardware acceleration of text, images, and vector graphics. Preview 3 completes the media landscape for modern websites with hardware accelerated video, audio, and canvas. Developers now have a comprehensive platform to build hardware accelerated HTML5 applications. This is the first browser that uses hardware acceleration for everything on the web page, on by default, available today for developers to start using for their modern site development.

Same Markup

As we have said before, web browsers should render the same markup – the same HTML, same CSS, and same script – in the same way. That’s simply not the case today across many browsers and many elements of markup. Enabling the same markup to work the same across different browsers is as crucial for HTML5’s success as performance. Our investments in standards and interoperability are all about enabling the same markup to just work. When developers spend less time re-writing their sites to work across browsers they have more time to create amazing experiences on the web.

The third platform preview continues to support more of DOM and CSS3 standards that developerswant. Examples here include DOM Traversal, full DOM L2 and L3 events, getComputedStyle from DOM Style, CSS3 Values and Units, and CSS3 multiple backgrounds. And as with each previous Platform Preview, the Developer Guide includes a list of all available features. We continue to work with the standards bodies and the browser web community to deliver same markup.

Same Markup: Video, Audio, and WOFF

At MIX we showed the potential for hardware accelerated video on the web. On the test drive site you can try out several examples of IE9’s support for HTML5 video and audio tag support. You can see for yourself how sites like YouTube for HTML5 works with video playing through the GPU. Here’s an example:

Note that while the video element in the HTML5 standard does not detail support for specific codecs, developers can still use the same markup to achieve the results they want. Coding practices should focus on testing for capabilities, not browsers, and providing the right fall backs for older browsers.

Also included in the third platform preview is support for using the Web Open Font Format (WOFF) through CSS3 font face. We were excited to work with Mozilla and Opera to submit the WOFF file format to the W3C, and in IE9 to bring high quality font support to the web in a way that is friendly to web designers, font foundries, and end users. As an industry we still have work to do for same markup with same results for font support.

Like all of the text rendered in IE9, the support for WOFF makes the most of the underlying hardware and Windows DirectWrite for high quality rendering with sub-pixel precision, resulting in smooth, crisp text across font sizes and browser zoom levels. In a recent article, Richard Fink from A List Apart wrote how, “The font rendering in IE9 is worlds apart from what we’ve all come to expect.”

Of course, the importance of WOFF support is having the same markup provide the same results for text and typography - results developers and designers can depend on. Here’s an example from the test drive site that shows a selection of WOFF fonts in IE9 and in latest shipping versions Firefox and Chrome. Some of the differences you’ll see if you try this example yourself are more precise layout of text and sharper characters at large font sizes and when zoomed.

Same Markup: JavaScript and ES5

Same markup includes running the same JavaScript code with the same results. The Chakra JavaScript engine in IE9 significantly improves support for ECMA-262: ECMAScript Language Specification standard, including features new to the recently finalized Fifth Edition of ECMA-262 (often called ES5 for short). This support for ES5 includes new array and object methods, as well as other language enhancements for working with strings and dates. The test drive site includes samples where you can try new array methods and play a game built with new ES5 capabilities. You can learn more about how we used ES5 arrays with a video look “under the hood” for the Tile Switch game.

Following through on having same markup across the web requires comprehensive and consistent tests. Unlike the standards body behind CSS and HTML, the JavaScript standards body has never had a place where the community could contribute tests. We’re working as part of the “TC-39” community with Ecma to create an official test suite for ECMAScript, sponsored by Ecma. In anticipation of this site, we’re making tests available on the IE Testing Center now for feedback via Connect.

Same markup: IE Testing Center and other tests

Some people use Acid3 as a shorthand for standards. Acid3 tests about 100 fragments of a dozen different technologies. Some are still in “under construction.” Some of the patterns, like SMIL animations, are inconsistent with others, like CSS3 animations, and need to be reconciled. As we continue to implement the standards that developers have told us they value most, the Acid3 score continues to rise, and we’re not done. Here’s a screenshot of how today’s IE9 Platform Preview runs today’s Acid3 test, going from 68 in the last platform preview to 83:

With today’s update to the platform preview, we have also updated the IE Testing Center, adding another 118 test cases which we are contributing to the appropriate web standards working groups at the W3C. In addition, we have written 1309 JavaScript test cases and are making those all available to the web development community. Another blog post provides details about them.

Performance measurement in web pages

Enabling developers to accurately measure website performance is important to delivering great HTML5 applications. Today, developers can measure different aspects of performance on their own machines with the Developer Tools; they can’t, however, measure the performance their users actually experience. Today, many sites develop their own libraries that try to measure live performance on web pages. The problem is that these libraries actually slow down the pages for consumers and measure inaccurately, driving the wrong behavior for developers.

We believe that the WebTiming specification is a good conceptual foundation for solving this problem. We’re in conversations with the W3C HTML5 standards body and folks at Google and Mozilla about this, and how we can all work together to make WebTiming happen in an interoperable and standardized way, sooner rather than later. We will work closely with the W3C and its members over the coming months to get this into an official working group and build consensus for a proposed specification while continuing to work together to ensure that the same markup works across browsers.

In order to keep making progress in the interim, we’ve included early support for these ideas in the IE9 preview. This is early work for sure, and following convention, IE uses a vendor prefix (-ms) on the namespace because the spec is genuinely under active construction. You can take a closer look at how this works in the WebTiming sample on the test drive site. We’ll talk more about this topic in a future blog post.

Test Drive IE9 Platform Preview Today

Our continued ask, is that you download the latest preview, try the samples on the test drive site, and try your own sites. Send IE9 the same markup that you give to other browsers. The IE7 compatibility view built into IE9, which some sites may run in, does not offer the best performance possible. If you still have sites that run in IE7 compatibility mode we recommend that you move those to IE9 standards mode. We want sites to get the full performance benefits of IE9 that come with running in IE9 standards mode. We also want your feedback from handing IE9 the same markup you hand other browsers.

The platform preview installs side by side with Internet Explorer 8 so that you can try it without replacing the full version of Internet Explorer that comes with Windows. This third release of the Internet Explorer 9 Platform Preview will install over the prior versions. There is no need to uninstall the earlier builds before installing the third. You’ll also find more information on what’s included in this release of the Platform Preview in the Release Notes, including known and resolved issues.

I love to see this progress, I'm very excited for Microsoft. However I'm really puzzled by the fact that people have to register on MSDN in order to see this news. Surely blogs should be public, otherwise you're not really informing the general community are you?

Any plans to allow any other font types into IE9? Because, honestly, as all other browsers support TTF and IE currently needs EOT, it's not really an improvement to let all other browsers still support TTF while IE9 now supports WOFF. It does absolutely NOTHING for developers unless Microsoft can cajole Opera, Google, and Apple to also support this format. You've merely replaced one "gotta do this tweak for IE" with two: "gotta do this for IE9+, and this for IE8-".

But you won't, I assume. So we will be once again stuck in time, with no reliable and universal codec solution. Think about it. It's money going away from our pockets, encoding video twice, serving videos twice. Far from ideal.

OMG the potato gun is the coolest thing I've ever seen. It's so awesome to see Microsoft getting your mojo back and doing cool stuff like potato guns and preview releases and blogs. For a long time you guys went all corporate and lost your personality. I've always been a Microsoft user but it stopped being fun when you became large and cold and stopped caring about developers like me that loved VB6 and IE4 and Office. It was all about the money for you for a long time and not making great software and doing cool technology. IE 9 seems different. I don't if it's the team or the marketing people or the competition or what but please keep it going and go kick some butt. It's almost cool to be a Microsoft guy again.

I'm unable to install the preview. It gets to the point where it says installing prerequisites – it gets to KB2120976 and stalls out saying "The installer has encountered an unexpected error installing this package. this may indicates a problem with this package the error code is 2739.

This is utterly fantastic! I had a feeling maybe this was coming, but it's brilliant to have confirmation. And fully hardware accelerated rendering as well! You guys deserve some serious kudos.

Funny though, I remember when the last preview was released, the comments were full of people screaming "No Canvas, IE sucks!" (prior to Canvas, it was SVG) Now Canvas is there, I guess lack of WebM support is the new reason to hate IE. And um, the FileReader API?

I love seeing the work IE Team is doing to stay competitive; each developer preview keeps getting "much better," not just "a little better." The hardware acceleration, full stride with HTML5, fonts, and scripting performance is flat out awesome. I have, and many others, steered clear away from IE after seeing the lack of performance and poor rendering (mixed proprietary, non-standard conformity) over each release, but now I'm anxious to see the final product. I'm crossing my fingers for your teams success. =)

I expected you would respond to the potato gun commercials with typical Microsoft marketing FUD. I honestly thought that I would arrive one morning to find a 50 page full color glossy whitepaper on my desk explaining how air powered potato guns aren't secure and would decrease my ROI. I never expected you to build an actual potato gun that we could shoot. Brilliant work boys.

@IE team: IE9pre3 looks nice. However, the score it gets on the following page: http://html5test.com is strange:

– it seems that IE9pre3 can't build an HTML5 tree; HTML5 support isn't there yet, if that's really the case. Or, your HTML5 markup doesn't match Firefox's, Chrome's and Opera's. Same goes for several other technologies (including canvas).

– don't forget about WebGL support: canvas ain't so good at 3D.

– The Acid3 score looks better; however, some remaining errors are bad: by now, there should be NO MORE errors in your implementation of getElementById! Moreover, you should really stop to try and sniff text/plain files, for security reasons.

@Mark: the FileReader API allows a web app to work on a local file without having to upload it to server first, or load it using the file:// protocol and cross-document operations (bad! Bad! Bad!). Hardly a security hole, it's more a privacy improvement than anything else.

@Matt: replace PDF, an industry and ISO standard, with XPS, a patent-encumbered proprietary format? I don't know what you're smoking, but you should stop. Really.

@hand, @Sylvain [MSFT] : Ah, didn't notice any official announcements on their parts about WOFF. In particular if Webkit doesn't support it, it really would mean WOFF was a useless change from EOT (not really changing the status quo). I did know Gecko supported it, though.

Is it better to report specific site crashes casually here, or file formal Connect reports? It seems on preliminary analysis that pages delivered as XML (application/XHTML+XML) crashes this PP.

@João Serra: While it may still be true that ChromeFrame uses the WinINET stack (they were still debating last time I looked) they have their own rendering engine, script engine, content parsers, image decoders, etc. From a security point of view, it has virtually all of the attack surface as a browser (actually more, due to the disconnect between the security model of the addon and its host). No intelligent and security conscious network admin will let ChromeFrame anywhere near their network.

Congratulations, guys! I love the enormous progress you're making on the browser engine.

However, you should also modernize the UI of IE and bring it on par with other browsers. Chrome, Opera, and Firefox 4 all will have beautiful UIs with smooth lines and animations. For example, IE8 now has the ugliest tabs of all modern browsers. In contrast – try reordering tabs in Chrome – it's just beautiful. And please remove the deep sunk border of the IE frame by default (set DOCHOSTUIFLAG_NO3DBORDER) – it looks so heavy and 1995…

In a previous post [1] I asked about the differences in format support between the AUDIO and BGSOUND elements, to which you responded, "The AUDIO tag will support AAC and MP3. BGSOUND will continue to support WAV." Is that still Microsoft's position, and exactly why are wave files not supported by the AUDIO element, given that it is already supported by your browser?

@Dan: The test is not bogus, in fact it is open source and you can look at the code. It is testing the canPlayType() method of the video element and that is apparently not correctly returning a true value. Thus the feature is not detected in JavaScript.

The video doesn't work in Minefield. I'd very much like to watch the video of the same markup working in IE9 and other browsers in, perhaps unsurprisingly, IE9 and other browsers. If you could provide a WebM version of the video (and out of the box support for WebM in IE9) that would be great. Thanks.

I was very happy to see box-shadow in this preview! It even supports multiple box shadows and inset shadows. I noticed a couple of bugs (the shadow isn't always drawn when scrolling, and it doesn't accept negative spreads). I'll file them in Connect.

Like they said in the post, browsers like Webkit have to provide lowest common denominator functionality since they're cross-platform. Also, which Webkit should they use? There isn't exactly one Webkit out there. They all have different degrees of standards support. It's not like Chrome and Safari are equivalent because they use Webkit.

Whats FUD? There are a ton of forks and ports of Webkit floating around, especially in the mobile space. So when someone says "just use Webkit." Which one?

And the lowest common denominator comment is totally true. For example, if a web browser wants to support hardware acceleration they could use OpenGL which is cross-platform. But then how are they going to support printing or handle font rendering? Firefox will use Direct2D like IE9, but Direct2D isn't available outside of Windows. So they will have to make some tough engineering decisions, and may have to maintain both D2D and OGL renderers, plus whatever they use for printing. So either you go the lowest common denominator route, or you take on a lot of extra work. Neither of which IE has to bother with, since its only on Windows.

@Gaurav: The HTML5Test.com wraps canPlayType and requires a response of "probably" unless the client is an IPhone, in which case they also accept "maybe". The IE9 PPB returns "maybe", but because of hardcoded browser detection requiring IPhone only, this is incorrectly classified as a failure by the test site.

You'll need to talk to the creator of this "standards test" to determine why they believe that returning failures based on the sniffed browser is a reasonable thing to do.

@Mathieu: If I recall correctly, for your GetElementsByName issue, you're hitting this only on elements that are not defined to have a NAME attribute in the HTML spec. Is that correct? Is there a reason that using an attribute selector wouldn't work?

Great work on IE9! I'm really looking forward to being able to rely on this being the baseline. I'll be able to make amazing apps.

Only things I'm missing are workers (all that javascript performance is no good if it blocks the UI), and webgl (although admittedly it needs to bake a little more before it is ready). Maybe you guys could get on board with the khronos group and help finalize the webgl spec?

Hey guys, great work on ie9, the third preview is showing great progress and i finally hav hope that we may one day get this browser war over with and everyone will support the standards. That way developers can write once and have it work everywhere.

I have one concern and that is the IE release cycle. In your graphs you are comparing IE9 to nighly or beta builds of other browsers, which is fine. But it reminds me that the other browsers update much more frequently to fix security, add features and update standards support. I am worried that when ie 9 comes out it will just be on par with the current versions of competing browsers including firefox, opera, webkit (safari and others), and chrome, but will very quickly become outdated as other browsers interate quickly and get faster, and more featured. Perhapse IE needs to start being updated with interim builds to allow microsoft to update the broswer, improve the core engine( javascript speed, and broswer speed) as well as add new technologies and standards. For to long developers have had to wait for major builds of IE spaced years apart, mabey it is time for IE to move a little more quickly and start release more frequently. Haveing interim releases like 9.1 or 9.0.1 would allow microsoft and IE to keep up with the quickly changing market that is the world wide web. I hope the IE team has a plan along these lines so that IE9 does get launch, raved about for 2 months and then forgoten as it is passed up by better and faster browsers. Leaving developers to wait in the wings until the next major release years down the line.

Great Job IE Team! It's great to see the SunSpider test results coming close to 100 and the Javascript engine performance get close to the pack leaders in this space. It's also great to see IE leading and creating W3C test suits so other browser makers can conform. Html 5 video is finally here in IE 9 as well! Lots of really good stuff and the hard work the team is doing is really showing.

I agree with Jason (above) about the more frequent releases and the fact that the other borwsers are not "preview releases" but rather production releases. What really happens is that the user see new features being implemented and websites working better (due to html 5 support) in other browsers and not at all in IE. So seriously think about beta release of IE 9 and frequent updates. Enough of this "preview" thing.

You guys need to change your focus to html 5 features that other browsers are focused on because those are the features that will eventually count. Features that are supported by more than one browser will start to be implemented by websites and browsers that don't work will end up getting a bad name. Check out Google's Html 5 playground

This site simply doesn't not function with IE 9. Besides, the features being shown off there are the features that "matter".

Incredible GPU acceleration is great but unless other browsers come close those aspects will not be used by anyone. Frankly I've had enough of the 60fps versus 12fps thing. I mean I get it and I love it but let's move beyond fps for now and do what others browsers are doing too.

At first this looks great but I can't take this blog post seriously. If someone are showing demos of html 5 stuff in several browsers and it only works fine in one (in this case IE) it can't be standard code. Did take a quick look at the code for the fish tank example and it look quite good tough… but something is fishy here 🙂 But as mentioned above, me also is tired that MS is always going there own way on what to support or not. When working with front-end development on a daily basis all I want is a standard code base. Good work with the development of IE9, will be nice to see it ship in couple of years when everything is changed on the web and we half to wait for IE11 to support the new technics, and the spiral begins all over again.

"As we have said before, web browsers should render the same markup – the same HTML, same CSS, and same script – in the same way. That’s simply not the case today across many browsers and many elements of markup."

Did I miss something?

Even CSS2 support is incomplete in IE8.

We don't want fancy graphics that only work in one browser, which only works on a small percentage of the computers in use.

We want a browser that actually renders standard markup and CSS correctly, like so many other browser vendors produce.

I solved the issue with the installation of the preview getting stuck on the downloading of prerequisite KB2117917 bij downloading the prerequisite straight from the Microsoft website. After the required reboot of that prerequisite the installation functions correctly.

Really good stuff, fantastic to see canvas in there. Keep up the good work.

@Shiv unfortunately the Google preview makes heavy use of -webkit and -moz extensions for the CSS3 demos, with no fall back for the final attribute (which the MS team ar keen on supporting from the start). Have a play with the CSS and you'll see it working.

Great news to see that Canvas is being implemented – I'm quite excited by IE9 now! Keep up the good work, and thanks.

One plea: please, please implement WebGL. As someone above said, Canvas really isn't up to scratch when it comes to 3D (even with HW accel), and webgl looks pretty superb. Even some kind of wrapper that allows people to write webgl markup and have it rendered via DirectX or whatever it is would be great.

There are many reasonable developers who complaint about IE's problems but actually want it (or any other major browser that's lacking) to have proper implementations of standards. Ultimately they'll be happy when it happens. THEY are truly part of the "developer community". I am one of them. I used to hate IE with every fibre of my being when its non-standard implementations gave me hell. But when it is changing for the good now, I really appreciate the work of everyone responsible.

But there are those who complain just to complain.. will never be satisfied with IE, yet somehow things that are not there in their personal favorite browsers are always forgotten or they are somehow universally accepted as not important. You people make a mockery of the term "developer community". You should call yourself "I-just-keep-on-whining-about-some-product-for-no-reason-community".

The container structure of XPS is an ISO standard and the format itself is standarised by ECMA. Also, Adobe has likewise a number of patents covering technology in their format, just read the legal notices in the Adobe Reader about window.

@raffi:

« Firefox will use Direct2D like IE9, but Direct2D isn't available outside of Windows. So they will have to make some tough engineering decisions, and may have to maintain both D2D and OGL renderers, plus whatever they use for printing. »

AFAIK, they will probably maintain implement even more renderers like OpenGL ES and DirectX 9, though most of this won't be available for common use anytime soon. HW acceleration is not going to be activated per default for Firefox unless they find some way to detect quirky hardware/drivers and such (there are plans for creating a community-supported project for creating a DB that might help in this).

They stem from an incorrectly-registered VBScript (2738) or JScript (2739) engine. I opened RegEdit, deleted HKCUSoftwareClassesCLSID{F414C260-6AC0-11CF-B6D1-00AA00BBBB58} and the install worked the second time around.

Looks nicer and nicer with each preview, http://www.css3.info/selectors-test gives 100% pass for css3 selectors. 83 acid3 score is also pretty good (not yet a 100 but hopefully with next preview or the final release it will edge even closer to 100/100 score 🙂 )

Canvas support is positive surprise and the font embedding looks nice and high-quality.

Will the 2d transforms (rotate etc) in css3 make it to the next release ?

@Indrek Actually the maximum score of acid3 is a 101, their is a favicon in combination with a 404 Not Found-error check which they couldn't find a way to test for. But I think all modern browsers have that down, including IE8 so it seems from first glance.

Anyone else having issues with the new preview not rendering pages after a couple of second? The pages are loaded, you can see the title and hyperlinks change as you browse around. But the actual pages aren't being displayed, 9 times outta 10 you're left staring at the home page.

Canvas, audio, and video support are huge, kudos to the IE9 team. However, what I really need now is Web Workers. Without them it's hard to do anything useful with the insane computational speed of all these new JS engines. So, what are your plans in regards to Web Workers?

As mentioned above in the comments, IE does not currently score any bonus points for codec support on html5test.com. You mention a workaround for a bug on the iPhone as the result for failing the test. This is simply not true. Without the workaround for the iPhone you would also score no point. The workaround is just for a known bug on the iPhone and does not impact the score of other browsers.

To check if a codec is supported I use the canPlayType function and specify both the mime type and the codec string. Without the codec string you can't say much about codec support, because there may be codecs that use the same container format and thus use the same mimetype. For example MPEG4 video and H.264 video both use the MP4 container and thus both use the video/mp4 mimetype. IE9 always returns "maybe" when it recognizes the mime type, regardless of the codec parameter. That means it will say "maybe" when asked if it supports H.264, but also when asked if it supports plain "MPEG 4". A response of "maybe" isn't wrong perse, but is simply makes codec detection impossible. And that is the reason why IE9 scores no points. It simply is impossible to test if a codec is supported.

Back to the workaround on the iPhone: it reports "maybe" when a codec is supported, but it reports an empty string when the codec is not supported. That makes a workaround for the iPhone possible. While not a pretty solution, I thought it would be best to show accurate results instead of false-negatives due to bugs. The bug in IE does not allow me to create a similar workaround though.

I have just checked the Asteroid Belt Sample on my Firefox 3.6.3 on Linux (Fedora 13 64bits) with no HW support for my graphical card, well the minimum HW support.

And it blocked for several minutes my workstation. Until Firefox asked me to stop a javascript which was using all the resources of my workstation… I was doing way less than 1 FPS, it was like 1FPM !!! or even less!

And only by this experience, I don't want to test the other things you presented on this page…

So, it is good in one way, but in the other way, the web is a place where everybody must experience something similar, and not have some discrimination on the OS/HW/Browser a user is using.

And if the trend is going that way… I am sorry, but does not help the users at the end… it will only be a show for techies in lack of sensation.

Do you want crossbrowser and crossplatform compatibilty? Do you want to have you content look the same in all browsers? Do you want faster graphics? Do you want to show your content to 97% of all people? Do you want more features like webcam, soundinput etc?

It's obvious there's only one choice: Flash. It's still way ahead of HTML5 AND can be enjoyed by almost everyone. You can't say that with HTML5. I still don't see valid reasons to jump into HTML5 if we've got this far more evolved method called Flash. Check http://www.flashlab.com

For all browsers I only accept "probably" as indication that the browser supports a codec. The only exception is the iPhone where I accept "maybe" as indication for codec support.

If I remove that exception for the iPhone, IE would still have to report "probably" to score any points, just like the other browsers do. I can't use the same workaround for IE. If I do, I would also have to report MPEG4 support for IE, which is a false positive. At the moment you simply can't distinguesh between MPEG4 and H.264 support on IE9, which needs to be fixed.

Some of these drafts are still in a very experimental state. WebKit engineers can actually be criticised for implementing these so "lazily". And in some cases, implementing a draft they created before they went to W3C with it. That's exactly what Microsoft did 15 years ago, why is Google/Apple better if they do the same?

Also I think IE has some support for certain block manipulation properties, but I'm not sure.

I could also list some things IE implements that Webkit doesn't [calc() comes to mind]. Your goal doesn't seem to be web standards but IE bashing.

> Wake up, people: Internet Explorer still has a long way to go to match Firefox and Google Chrome's features.

We all know that. But please wake up yourself as well.

WebKit has probably the worst implementation of CSS 2.1; I do not judge by Acid tests, I judge by extensive test suites like the W3C test suite for CSS 2.1;

If I compare how current engines work with CSS 2.1 from an authors point of view, ignoring the browser I like the most, I'll get this:

IE8/PP and Gecko are on first place (IE is more complete but Gecko less buggy), Opera/Presto on second place (it still has some IE imitations and a few bugs here and there) and Webkit on a distant third place (KHTML is probably worse).

I'm working with web standards for over ten years now. It's true that Chrome's speed is just darn amazing, but don't let this blend you and ignore the many bugs that the engine still incorporates.

This is great work in proactively implementing HTML5. A lot of developer friends and I were wondering if HTML 5 wouldn't realistically be adopted for another 10 years because of past IE adoption track records. This looks like it'll happen a lot sooner and that's extremely exciting.

However, PLEASE PLEASE PLEASE PLEASE DON'T RELEASE IE9 UNTIL IT PASSES (passes mean 100 btw) THE ACID3 TEST!!!!! Sorry for caps, it's annoying, I know. Also, please refer to quirksmode to try and implement as much of the other browser features as possible.

Over the past few releases of IE, my websites have "broken less" with each release. However, all of the other browsers don't break. So, if you do pass (100) the acid3 test and implement features in the html5 standard, couldn't you "recall" all of the browsers that "are still reeking havoc" in the internet. Namely, IE6 (still a-grade). But I wouldn't complain if ie7 and ie8 died with it.

This is a promising advance and kudos on being proactive with html5, but we could really just use a cleanup of past mistakes at the moment.

@Alessandro: Firefox 3.6.3 (on windows) will run the Asteroid Belt sample, although you have to constantly move your mouse to actually see the results. And firefox having no HW support on linux is a problem you need to bring up with them not blame IE 9 for supporting available hardware just because the platform/OS/browser you chose doesn't support it. Opera, Safari, IE9 all run the sample just fine. Firefox is buggy, and chrome is horrid, but it works.

@Wurst_off: if 3D was limited to polygons, gradients, textures and such, I'd agree; however, SVG is a 2D vector graphics format, which requires:

– managing a Z-buffer yourself

– not using any programmable effects (shaders).

So, while it IS possible to do 3D stuff with SVG, it is not possible to use advanced effects and/or hardware acceleration when available. It is possible to do VERY nifty stuff with SVG, but not in a way that matches current GPU accelerations. Also, vector-based rendering isn't the only one: one could prefer voxel raycasting, ray-tracing, etc. to render a specific, all rendering systems that OpenGL supports – but that can't be emulated efficiently in SVG or in a canvas element.

So, I'm not saying SVG support is bad; quite the contrary, actually – I just got overjoyed seeing SVG was now a native image format for IE.

It is also possible to do nice looking 3D using a JS physics library and a JS 3D engine for SVG. But this would be much, much slower than using the same JS physics library on a WebGL element… And not as capable.

2D and 3D are NOT the same, and considering there's already an OpenGL compatibility layer in Vista and 7, implementing WebGL in IE 9 wouldn't be THAT difficult.

@RobertM: Firefox on Linux has hardware acceleration, but not the kind you get from Direct2D: on Linux, Firefox will attempt to make use of the RENDER extension – which makes it:

– render fonts with filtering and hinting in a way that is much, much better than on Windows with GDI

– render canvas a bit faster, on drivers that support RENDER properly, than Windows with GDI.

@Rolph Myersen: forget about Silverlight on Linux: Microsoft didn't publish it. The best you can get is a beta plugin of Moonlight 3.0, and then the h.264 decoder from Microsoft. It works, more or less. Better, it works as a user-space plugin (which is recommended, because the plugin hasn't been audited for security yet).

Had this blog published the video in Theora format too, everybody (but IE 8 users) would see it hassle-free.

@Dave: I have yet to find a CSS 2.1 property IE 9 didn't implement properly. CSS 3 still being in some flux, I can only complain about the lack of box-shadow (-ms-box-shadow wouldn't be frowned upon).

To sum up: I'd enjoy WebGL quite a lot. I'll be very content to only get an IE 9 wersion that, in coming years won't be a pain to support (like IE 6, 7 and, to a lesser measure, 8) but only 'yet another browser with nice features and speed but some quirks'.

It will be really good that IE stops being the Ugly Duckling of the browsers.

As someone commented above it would be nice that besides all the hard work on GPU features you start focussing now on HTML5 so you are not the only future browser with bad numbers here whencaniuse.com

Believe me when I say that the IE team always had good intentions for standards support for IE7 (http://bit.ly/dn1NKA) and IE8 (http://bit.ly/aG3ezW) but the implementations weren't as good as their intentions in the end. I hope this time is different for IE9.

One thing I recommend the IE team though is to stop using misleading demos. Comparing your GPU speed of your *future* browser against *current* browsers that use only CPU is more of a marketing strategy than a sound technical comparison. Please compare your demos against other GPU implementations… or just stick to the numbers or the acid3 test improvements and developers will love your effort without thinking there's something smelly behind it.

Right, 60fps is worse than 1fps, FF3.7 has a better SunSpider score, a <100ms improvement on S.S. is going to make a difference on my day to day browsing, and Chrome/Safari's lack of hardware acceleration ultimately results in faster performance.

>>2. Seamless malware / spyware infection.

Right, because SmartScreen isn't blocking over 2 million malware sites a day. [1]

>>3. CSS anomalies

Right, because IE doesn't have the most complete CSS2.1 implementation and Webkit doesn't implement things loosely in final releases before they've been solidified in the W3C.

>>4. Useless add-ons

That's why Firefox was such a fail initially and Chrome's "extensions" are being phased out.

Congrats to the guys and gals at Microsoft. Good to see the company taking the browser *much* more seriously. If the jump between the previous IE and IE8 is any indication of things to come, I can't wait to see IE9 unleashed!

@Shiv Kumar: Thanks for the comment. This is an important conversation to have.

We pay close attention to what HTML5 sample sites are using, what browsers are implementing and most importantly, what developers really want.

It’s important for samples like those on our test drive site to work across browsers. This helps us all achieve the goal of rendering the same markup.

Some sites such as http://www.html5rocks.com do browser detection and block their experiences in IE. For example, html5rocks.com checks for IE using navigator.userAgent.match(/MSIE (d+(?:.d*)?)b/) and displays a warning instead of its HTML5 samples. This why feature and behavior detection are a better choice for site developers than browser detection.

We’ve verified in a test environment that http://www.html5rocks.com works in IE9 when browser detection is bypassed. Canvas, video, audio and other HTML5 features in IE9 come to life. We are reaching out to Google and other site developers to request that their samples work across browsers.

I think that instead we are enabling chrome frame for most of the sections because it was impossible to run it well with any of the IE versions. I will be more than happy to remove any filter so you can run it with IE9.

"We are reaching out to Google and other site developers to request that their samples work across browsers."

I didn't receive any email yet but please do. I want IE to be present along with all the other browsers.

"The canPlayType(type) method must return the empty string if type is a type that the user agent knows it cannot render; it must return "probably" if the user agent is confident that the type represents a media resource that it can render if used in with this audio or video element; and it must return "maybe" otherwise."

Meaning:

– If a browser returns "probably": the codec is supported by the browser itself.

– If a browser returns "maybe": the browser itself doesn't support that media type, but it may have a plugin that does (most expected case). However the plugin may not be able to send back uncompressed video data for the browser to display and handle.

– If a browser returns "", the codec is not supported at all.

Reasoning behind the 'maybe' value: most plugins register the resource types they can handle, but some lie about what they support (thus why a browser can return 'maybe': the plugin may say it can do it, but actually do nothing when fed the data). If a browser returns 'maybe', you can then list what plugins are present, and get name and version for a given plugin that you know works – or, on the contrary, a plugin known NOT to work – and make up your mind after that detection: load an external playback interface (Flash, Silverlight/Moonlight) or rely upon the browser.

IE 9 has h.264 built-in, we're told; as such it should return "probably" on a query of the type media.canPlayType("video/h264") or media.canPlayType("audio/x-aac").

If it doesn't, it doesn't follow the expected syntax. So, the test is right, and there's a bug in IE9. Before you claim a test to be bogus: read the spec.

If IE 9 returns 'maybe' for all codec types, it may be because it relies upon Media Player to do the actual decoding; that would be sensible, but then it would also mean that IE 9 will NEVER return 'probably' for any codec – forcing developers to do browser detection on top of media detection to determine if the browser supports the media or not for EVERY media type. And browser detection is bad.

This is all awesome news, truly awesome news – it must feel great to finally be proud of IE's abilities.

However as I read all this news and become excited about it – I momentarily forgot something…. all of this is useless until IE6 dies, IE7 dies, IE8 dies, and Windows XP dies (all needed for IE9 to become the lowest baseline)

Since IE6,7,8 all live quite happily right now on XP (and have done for a decade) with no end in sight in the next decade – this new stuff in IE9 is all a great big MOOT POINT.

I also wonder – If by cheating and pushing JS processing to the GPU only "ties" you with other leading browsers… then just how slow is IE9 at processing JS without the GPU? Was there any fixes to the core JS engine beyond the solution of "throw more hardware at your performance problems"?

One can only presume that Firefox, Chrome, Safari and Opera will all do the same (harness the GPU) when they are ready – at which point we can only presume that IE won't look at all shiny and new in comparison.

Finally, you've also removed all the chrome/settings/tools/dialogs in the platform previews (good) but have they (internally) been revamped also? The current set of supporting chrome and dialogs for IE haven't been updated since IE6 and look as tired and dead as windows 2000.

I ran into the same problem as José did. This is on Windows 7 x86 on a notebook with indeed an associated ATI graphic chip. There's no driver update available for that one (no surprise) and uinstalling the driver isn't an option of course. But the problem as such vanishes as soon as you uninstall the "helper" update KB2028560. Strange.

<<<IE6,7,8 all live quite happily right now on XP (and have done for a decade) with no end in sight in the next decade>>>

Wrong. XP SP2 is completely out of support on 7/13/2010. SP3 is in extended support (security fixes only) until 4/2014, which means that it gets security fixes only, not functionality fixes. Windows 7 has the fastest uptake of any operating system in history, and already is the most popular OS on Valve's Steam.

"If IE doesn't, it doesn't follow the expected syntax. So, the test is right, and there's a bug in IE9. Before you claim a test to be bogus: read the spec."

If you were right about the syntax that would still only mean that IE9 does not comply with the canPlayType syntax. So the use of canPlayType is what is given bonus point for. Not for actual support of the codec as the test page claims.

@hAl: Yes, it was announced at MiX 2010 (and on the blog) that IE9's Video tag will natively support h264 in an MPEG4 container. It will also support WebM if the user has installed that codec separately. For the Audio tag, MP3 and AAC are natively supported.

@hAl: Calling a test "bogus" isn't helpful. The test is written in JavaScript, and has to rely on feature detection in that language.

@NielsLeenheer, @EricLaw: Let's try to determine the correct JavaScript code to reliably detect which encodings are supported by IE9 so that when someone wants to know if their video will play, they can use it.

You ask the postman: 'can you deliver a parcel to the other side of the street?' The postman has 3 possible answers:

1 – sure, I can! I'll do it myself right away.

2 – well, maybe I could, but I'm not sure because I'm not the one who takes care of the delivery itself – I have to hand it out to someone else.

3 – I can't, sorry.

Would you entrust this postman with your package if he answered 2 or 3? Here, it's the same thing – IE9 claims that it may be able, but is not sure, to decode h.264 and aac. Would you trust a browser to playback your media in that case? Well, me, I wouldn't.

Considering the IE team recommends to do feature detection and to use 'every-browser' syntax, the very fact that it doesn't return proper answers on canPlayType method is akin to saying, IE9 doesn't support h.264 nor aac etc. as far as cross-browser feature detection is concerned. It's a bug that must be corrected.

but: http://www.css3.info/…/multi-column-layout Please please please please please! It's in the MS Office for over a decade. Rip it off and make it work in the IE9 please! FF and Chrome already supports this and now the Opera is likely to implement it. Hundred times more important feature request than any multi-background stuff. Please please please please please!

@hAI: canPlayType is explicitly there to test codec support and there are very specific rules in the specification when a browser should report what. IE9 does not follow those rules at the moment and the result is that codec detection using canPlayType is impossible at the moment. IE will report the same thing for a codec that it does support and a codec that it doesn't support. IE isn't the only one with this problem, the iPhone has it too, but that doesn't make any less of a problem for users of IE.

You are absolutely right that an error in canPlayType isn't the same as not supporting the actual codec itself, but then again, if the browser does not correctly tells what it supports, you can't complain about wrong test results.

@Guarav: Agreed. I'm not here to complain about IE. I think IE9 will be a great release. Initially I just filed a bug at Microsoft Connect about this and hoped for a quick solution. But given that there were some comments here stating that the problem was with the html5test, I had to try the set the record straight.

But why do you work around the bug for the iPhone? Surely, by definition, a standards test should not include workarounds of this nature, because if a browser behaves incorrectly then it is not conforming to the standard?

Agreed. At the time it seemed sensible to add a workaround for this specific problem on the iPhone because which codecs to support is not defined in the standard and while the iPhone is wrong, is it actually consistent in its behavior and you are able to reliably test which codec is supported. Now that IE exhibits a similar problem I am considering removing the workaround for the iPhone. Proper support of a codec not only means being able to decode video frames, but also that you properly report back if that codec is supported. If IE fails, so should the iPhone.

What I can't do is simply add another workaround for IE. Because unlike the iPhone you can't reliably test which codec is supported in IE. Both codec that are supported and codecs that aren't supported give the same result.

I am now impressed. I’ve given you a real hard time because I have been enjoying availability of features in other browsers and IE lags badly, but I can see now that you are putting in a very solid effort to put IE on the straight and narrow.

I’m concerned about software rendering speed, IE9 on my netbook can’t play HTML5 video smoothly, but other browsers can. I suspect that software rendering optimisation is a late-in-the-game task and I’ll be fine to wait until a release version. I found the HTML5 video element lacked a context-menu (download, full-screen &c.) but again, nothing that can’t be easily fixed in due time.

Support for camendesign.com has moved on, some of it renders, but it’s still broken in an odd way. The site has no head/body tags as the spec allows, but the automatic placement of the body tag by IE is occurring after an HTML5 header and article element instead of right at <header>. Understandably, I ask if you could fix this please in your time.

I’m genuinely impressed, please continue to fight for "same markup", it’s your best bet against Apple who have a one-browser view of the web and are looking to tie the web to Safari / WebKit so as to sell millions of iDevices.

As far as I'm concerned, 83/100 in Acid3 test is by far the IE9 team's most important achievement. Everything else is just icing on the cake. I truly hope you'll get to 100/100 before releasing the product.

One feedback: on the video panaroma test, the animation works smoother on IE9 over Chrome. But, the movie plays smoother on Chrome. On IE9, the movie frame was skipping and slow, while on Chrome it runs smooth. You should look into that. I have a pretty good h/w and internet connection, so that's the not issue.

adem >> XP is not supported. Direct2D, DirectWrite, and all the cool stuff, aren't supported on XP. Besides, XP will soon be 10 years old. You should upgrade 🙂

Michal Tatarynowicz >> That is completely wrong. Acid3 only tests 100 features – it doesn't mean anything. The rest is much, much more important. Besides, like Mozilla, MS won't be implementing SVG Fonts, so no 100/100.

I just published an article about detecting HTML5 codecs and the problems you will encounter. The bug in Internet Explorer 9 I mentioned earlier is featured, but IE is hardly alone. All browsers so far – except Opera – make mistakes. Unfortunately they don't all make the same mistakes, so detecting codec support is still unreliable. While some mistakes are not that serious, some are, including the iPhone and IE9. Read the article at: rakaz.nl/…/problems-with-html5-video-codec-detection.html

@Honesty: well, the postman can do it – he may not achieve it (who knows, he could be run over by a truck while crossing the street), but he can do it. I think that's the reason there's no 'yes' answer, is that an error could still happen (invalid stream, say) and the browser would give up performing the rendering.

And, frankly, if your postman answers only with 'probably', 'maybe' or 'no', he's not going to stay your postman for long – you'd go FedEx…

I thought it'd be more understandable, and I was sure I'd get a flame about a postman using canPlayType's vocabulary would be rather unrealistic… I got hit the other way, d'oh!

Platform Preview may work without the update but rendering performance will be greatly affected. ATI provides reference drivers but not always for laptops. Laptop OEMs provide drivers of course and Windows will often times have an in-box driver that works.

Hi am facing the same problem as Jose. But the driver seems up to date. Any other recomendation. It seems that my windows live messenger Beta also crashes due to same error. And right when I was trying give my wife a demo of how amazing it is. Any recommendations?

Great article, Niels! Now, does this mean you’ll be removing the workaround for the iPhone? I know you said you were contemplating it. I think it’s the only fair thing to do. Also, it would make sense to then change the wording above the test results to say something like, “If a browser *claims support* for one or more video codecs, two bonus points are awarded for each codec.”

Otherwise, good analysis. This stuff is important to hash out in the name of “same markup.”

…but I'm a bit surprised about the performance, it really performs wonderfully in the demos which uses a few elements but redraws the entire screen every frame, but in my own testing, rendering many simple small shapes hurts performance very badly, text and clipping hurts the performance something fierce. Is this something that will be improved upon before the final release or is the performance one can expect?

Other browsers such as Chrome/Firefox can render huge amounts of elements very quickly, but performance hurts very badly from larger viewports. Which is kind of funny, because all browsers might actually implement the specification correctly, but due to the large differences in how they perform in various scenarios… might end up making it not so universal in the end, as optimizing it for one browser means that it might perform considerably worse on another. IE9 vs Chrome would seem to perform opposite of the other in most scenarios.

On another note, is there any API for actually rendering in tune with the monitor or determining the HZ of the monitor? Aka, how is one supposed to render just ONCE per frame. Using a timer with 1ms delay works, but isn't really optimal and on chrome means you'll be rendering at 250 FPS which is not great.

Will cleartype/subpixel rendering ever be an option when rendering using the canvas? It would seem like a natural thing, being able to render text that looks gorgeous, while also being able to render antialiased text that can be saved to an image. Instead of just being able to render blurry antialiased text.

you are the ignorant troll here, and you even posted after your "last comment on this post", you are such a loser lol. You are the one who should really stop after your declaration of "last comment on this post", but obviously you are too pathetic that you can't even keep up your own word.

And your customers are all losers if they use that pathetic Chrome Frame plugin instead of Google Chrome itself, and you are the big joke if you tell your customers to use Chrome Frame instead of Google Chrome proper. If you want to use some specific APIs, go ahead, but it's just ridiculous to recommend people to use Chrome Frame instead of just switching to Firefox or Google Chrome proper. You are obviously a moron to do that, lol.

EricLaw, right. Indeed, one can safely replace .getElementsByName('element_name') with .querySelector('[name="element_name"]'). It's a solution that works on all main browsers. This still remains a cross-browser compatibility issue.

Also (in the hope some IE developers are still reading comments from this post), is there a plan to fix the infamously broken select element's innerHTML? (support.microsoft.com/default.aspx)

I did of course tried and did have the latest driver available from Lenovo for the Radeon HD 3400 installed. That's the one that failed with KB2028560 beeing installed and let IE9 P3 crash. The older, previous version of the driver doesn't leed to a crash in IE9 P3 with KB2028560 installed – but looking at the frame rates, it does seem to be slower in preformance than the actual one *without* KB2028560 beeing installed. Weired.

2) I know you have PR guys/gals at Microsoft that must do their thing, but please stop the FPS Hardware Accelerated trumpet blowing and devote more time to making IE support more standards. [see next point]

3) Really good job on Canvas, i feel it brought you a lot of well deserved media attention. Now i really feel that IE team is serious and i see a change at Microsoft. Hope this new guard raise in rank. Can a leopard change its spots?

I hope to God that IE9 will start in a "true" fullscreen window everytime the browser is launched like (Chrome Firefox, Opera) ?? What's the point of starting the browser in the same window size as a default nodepad window (as IE 8-)? 😮 I don't know anybody who vies webpages like that so 99.9999~ of the time one immediately resizes the client window to maximized size… why not do this per default??

@another_anon: That's simply how Windows works. In IE's case, we start the new window in the size of the last closed window. If you want to make IE start maximized every time, create a shortcut to IExplore.exe and in the shortcut properties, choose "Start Maximized".

@another_anon: Going along with EricLaw, that is just how Windows works (and I like that). In fact, you're wrong about Chrome, Firefox, and Opera. On my Win7 machine, they all open in whatever the size of the last closed window was. And if you ask me, that's the way I want it.

I fail to install on Windows 7 Proffesional x64. It just stops on the first of the 3 updates required to install, and when I try to install them manually I get an error stating that the updates are not for my computer… Is there anything I can do to get ie9 platform preeview running?

I used to be a Microsoft Man, with all the software on my computer being Microsoft offerings, but over the last few years, security issues, APPCRASH problems, bloatware and slow speed experiences, have made me change allegences to other manufacturers, but, after seeing all the hype about IE9, I thought I would go back and give Microsoft a try again.

Well… it's great that IE9 is trying to make the web experience richer, but *WHY* isn't the IE9 team focussed on meeting *ALL* HTML5 and *ALL* CSS3 specifications *FULLY*, before adding the bells and whistles ?

Internet Explorer should have been dumped years ago, and a new COMPLIANT web browser written so that there wouldn't be all these arguements, and heated discussions. The browser would just have to be updated to meet any new specifications, and all the nice-to have "extras" would be plug-ins/add-ons.

It looks like IE9 is going to be yet another massive download and install, that still won't render the web as it is supposed to.

Sorry, but I think I will stay away until Microsoft announces that they are writing software to meet standards and help users, rather than making up "standards" that they hope will be adopted, but that no-one else supports. Coding a web-site is becoming a pain in the ar5e, testing for ie6, ie7, ie8, ie9, or everything else!

"Well… it's great that IE9 is trying to make the web experience richer, but *WHY* isn't the IE9 team focussed on meeting *ALL* HTML5 and *ALL* CSS3 specifications *FULLY*, before adding the bells and whistles ?"

You do "some" job but this is stil low peformance graphics for today standards. On may lap (i7 with gt330) I have 25fps in 250 fishes tank, do you recommended to use desktop and gtx480 to have smooth animations or you made browser for next decades laps? It's a same you are OS producer and can't made optimized gpu powered software. Don't look in open source and other browsers just look in games powered with the same technologies and you'll see whare are you now. And other technologies like webkit and webgl sholud be implemented.

@goxy: I'm not sure why you're not seeing higher performance. On my 18 month old Lenovo x200 laptop with a last-gen Core2 processor and the integrated Intel GMA X4500HD, I get about 41 FPS with 250 fish.

@EricLaw: I use full HD, I guess that's the reason, what resolution do you use? Also this tests are not in real resolution, on the right side there is browser resolution in this test and my case there is 1280×616, so in fullhd I should expect and even lower. If I compare fps in presented video, I think their GPU is much more powerful then mine gt330m, probably some desktop high end class. I have low performance on Amazon test too, this is better then Flash and Silverlight but still not real smooth motions.

The "resolution" shown on the right-hand-side of the test case shows the pixel size of the browser window, not the pixel size of the screen. "Full HD" is a misleading term, since even if you mean "1920×1080", the content area of the browser window isn't that large.

@EricLaw [MSFT] Why browser window is not in real screen resolution, probably because this "GPU acceleration" is only marketing term, this is still slow peformance browser and nothing else. When my lap powered with i7 on 2.8 ghz, DDR 3 on 1.6Ghz and gt330m with 1GB can not render simple "GPU powered" animation with more than 25fps in 1280×616 pixels I know problems are in programers that made this "animation". I had better peformances in games on intel i750 GPU 10 years ago than this engine end brand new lap.

The browser window isn't the same size as your screen because there's a title bar, menu bar, and status bar that take away space. Thus, the content area of the browser is smaller than the content area of the screen.

I'm afraid I have no idea why my much older and slower laptop runs the demos much faster than your newer laptop which has much better hardware. I can only assume that you've got something else misconfigured on your laptop (e.g. hardware acceleration disabled, etc). You'll probably want to check your task manager to see what your CPU is up to, and ensure that you're running the latest drivers for your graphics card.

@EricLaw [MSFT] Title bar, menu bar, and status are above layout so resolution is smaler in high, in width should be the same. I have latest drivers and directx, Need for speed game is smooth in 1920×1080 so I guess system working properly. I try this examples and on friend of mine desktop with ati 5870 and we had similar results, the best example is Flying Images demo, if you zoom in you will see movement is not quite smooth, I dont know reason, I can't beleive example is bad and movement resolution is not enought fine.

@EricLaw [MSFT] and Klimax: Just look in IMDb Video Panorama example on IE9 Test page, look in picture and title text and try to move from one to another one, text is unreadable on even slow speed and pictures are with blur whatever CPU and GPU you are using, I try this on several PCs. IE9 has real limitation in object movement, probably reason is slow drawing engine.