We’ve had 10 million downloads in the six weeks since we released the IE9 beta. That popularity reflects the significant improvements in browsing that IE9 brings to the web. Users can pin sites directly to the Windows task bar, and sites can program jump lists and offer notifications just as Windows applications do. The web standard markup (HTML, CSS, and script) in pages runs faster and smoother, taking advantage of modern PC hardware.
The popularity of the beta also reflects the early exposure to and extensive impact on IE9 that developers have had. Developers downloaded the first five Platform Previews over 2.5 million times. The sixth Platform Preview of Internet Explorer 9, available now, reflects developer feedback and delivers better performance as well as more standards support, like CSS3’s 2D transforms:
In addition to several new test drive samples, you can find more examples from the broader community of what’s possible with a great HTML5 implementation at http://kexparchive.org/ and http://10k.aneventapart.com/. Each of these examples shows how the web becomes richer and more immersive with HTML5, and how tapping the power of the whole PC is increasingly important to deliver the performance consumers expect.
We think people should evaluate performance with real-world scenarios. Real-world scenarios involve using all the subsystems in the browser together rather than looking at single subsystems in isolation. For example, the IE Test Drive site offers samples that deliberately represent real-world site patterns rather than microbenchmark-style samples. The visualization of the real-world samples is often more fun than a graph, as in browser hunt and speed reading.
Engineers design microbenchmarks to isolate and exercise very narrow and specific aspects of a system. That’s the opposite of real-world websites that use the different subsystems together in order to deliver something useful or entertaining. Measuring the performance of a browser, subsystem by individual subsystem, is inherently flawed because it’s not how real sites work.
Side by side comparisons of different browsers running real-world samples show significant differences. The new SVG Helicopter test drive shows performance differences between browsers on sites that use SVG and script together with HTML5 audio. In Track splash, you can see the performance differences between browsers when HTML5 video interacts with canvas. This customer model also shows performance differences in SVG when you zoom in and out, a common activity in wading through data. Unfortunately, you can also see differences in how different browsers display the same SVG in the real world samples as well; as an industry we have more work to do so the same markup delivers the same results.
The differences between browsers on this microbenchmark are converging within thousandths of seconds on tests that repeat operations many, many times to find any differences at all.
We think people should evaluate web standards compliance through an industry standard test suite. On the web today, individuals have many choices of tests to assess and use as shorthand for standards support. Unfortunately, each test in its own way is incomplete and has inaccuracies.
We look to the standards body for a test suite to assess the quality and completeness of a browser’s standards support. The W3C’s open and consensus-based approach is the best way to bring the community of browser vendors and web developer and design professionals together in building a comprehensive and accurate test suite.
Test suites are a crucial complement to specifications. The benefits to consumers are clear looking at USB devices and wireless networking hardware, and the market’s higher expectations around interoperability from those products.
The goal of standards and interoperability is that the same HTML, script, and formatting markup work the same across different browsers. Eliminating the need for different code paths for different browsers benefits everyone, and creates more opportunity for developers to innovate. Developers face a hard challenge today: they need to work harder than they should, to write more and different HTML, script, and markup, just to get similar but not always the same results across different browsers. When developers spend less time re-writing their sites to work across browsers they have more time to create amazing experiences on the web.
In the short term, developers will likely focus on delivering HTML5-enabled sites that work well (as designed, and with good performance) across browsers. That’s a pattern we’ve started to see as sites enable HTML5 video support, and it makes sense. Tuning sites for specific performance characteristics of different browsers may, longer term, make sense for developers as well.
At the IE test drive site, you can try some other samples of same markup running across different browsers. For example, Flickr Postcards shows same markup for CSS3 2D transforms in action. Semantic Notepad shows the same markup for HTML5 semantic elements, and A New Day shows the same mark-up for CSS3 box shadow.
Our investments in standards and interoperability are all about enabling the same markup to just work across different browsers. With IE9, we’re doing for the rest of the web platform what we’ve done with CSS 2.1. Developers should expect more from across the industry on this front in order to make HTML5 applications easier to write.
People on our team actively work closely with Microsoft customers to reduce IE6 usage, helping them to migrate their key sites so they can switch from IE6 to a browser with better performance, standards support, and safety.
Sites that code browser detection rather than feature detection are one of the hardest obstacles they face.
As an example, someone recently asked me about this page because the site told him that “You are using an out-of-date browser version. Please upgrade! Many features of our new site may not be supported in your browser.”
The page incorrectly detects IE6 by running a script from this file – prompting any IE user running a version other than IE7 or IE8 (“ltIE7 = (client.isIE && !client.isIE7 && !client.isIE8)”).
ltIE7 = (client.isIE && !client.isIE7 && !client.isIE8)
You can see similar patterns in many other pages around the web. For example, this page incorrectly initializes a canvas library for users of any IE version, rather than using IE9’s native canvas support.
Sites that use feature detection are better off. As browsers and standards change over time, these sites will continue to work, and as a community we avoid part of the “IE6 phenomenon” of sites hard-coded to browser specific behavior.
With the sixth Platform Preview, developers, designers, and partners are in a great position to prepare their sites for the IE9 Release Candidate that will follow Platform Preview 6 and precede the final IE9 product.
Platform Preview 6 is an important milestone on the way to the Release Candidate (RC). The IE9 platform is nearly complete. We appreciate your help delivering a richer and faster web that takes advantage of the new web standards the IE9 Release Candidate will support. We continue to welcome your feedback via Connect.
Thanks, Dean Hachamovitch