Early IE9 Platform Preview results show promise

We've argued that Microsoft needs to engage more with Web developers to give a better understanding of what the company is doing with its Web browser, allow them to provide feedback throughout the development process, and more broadly get them engaged with the development process. With Internet Explorer 9's Platform Preview, Microsoft has indeed taken steps to do exactly this. Though Microsoft still isn't releasing the nightly builds that other browsers offer, the Platform Preview definitely represents progress; it provides early access to IE9's core rendering and JavaScript engines, and will be updated approximately every eight weeks.

The eight-week cycle was chosen because Redmond felt this provided the best trade-off between getting regular updates into developers' hands, ensuring that the preview releases are reasonably robust, and getting useful feedback that integrates well with Microsoft's own development processes. Each version will undergo reasonably extensive testing during the eight-week period, giving ample opportunity for bugs to be filed. For its part, the IE team has committed to investigating every single bug filed, and resolving all that it can.

Indications are that the Platform Preview has thus far been quite successful. Sources close to the matter state that some 700,000 copies of the preview have been downloaded, and that interest has been global in spite of the preview being a US English-only release. The top three bug report areas are SVG, compatibility, and then CSS, which certainly indicates that developers are taking an interest in testing the browser's new features and ensuring they work correctly. Of the hundreds of bugs filed thus far, the same source says that around 60 percent of them have been addressed by the development team.

These download numbers are substantial, and it could be make a good case in favor of this slower release strategy. The Mozilla group's weekly Status Meetings include information about the number of users of different prerelease versions of Firefox. During the lead-up to the release of Firefox 3.5, several hundred thousand people used the major betas, but the nightly releases were much less used, with perhaps 10,000-15,000 users. The Platform Preview is not anything near as usable as the Firefox betas, so 700,000 downloads is a strong showing.

Ars talked with IE General Manager Dean Hachamovitch briefly about the Preview. He said that IE9 testers seemed particularly interested in the browser's performance and graphical capabilities, as these areas of the IE 9 Test Drive site had received most traffic. This is also reflected in some third-party reactions. NVIDIA recently used the IE9 Platform Preview to promote the graphical capabilities of its new Ion2 platform—capabilities that IE9 can, of course, exploit due to its extensive hardware acceleration (the same hardware acceleration that leaves Windows XP users out in the cold).

Stability vs. automation

Microsoft's approach to browser development shows a strong commitment to the ideal of a stable, versioned platform, something that developers could reliably target for consistent results. This attitude is carried through to the Platform Preview. Unlike, say, Chrome's dev channel which automatically updates about once a week, ensuring that developers always have access to an up-to-date version, the IE9 Platform Preview will require manual updating. Though this has the obvious downside that developers might forget or not notice that a new version has been released, and hence may result in testing of obsolete versions, it maintains the important (to Microsoft) notion of predictability. With Chrome, a page might work one day and be broken the next by an automatic update, a behavior that can be confusing at best. Microsoft doesn't want IE developers to face a similar experience; instead, they will have to take deliberate action to update.

On the other hand, automatic updates are, in a sense, part-and-parcel of the Web experience. Websites can change their appearance overnight, and while this can be confusing to some, it's an unavoidable fact of Internet life. The case can certainly be made that browsers should follow websites' lead and update themselves; this gives users a browser that (by and large) keeps on getting better—faster, more capable, and with new features. Though occasional regressions will happen (wherein a new version breaks something that used to work) a robust development process should make these rare.

These advantages were acknowledged by Hachamovitch, especially for the more savvy, technically aware user (that is, users who are unlikely to be fazed by new features and improvements appearing within their browser automatically). But the company still prefers to take the more conservative approach to avoid problems of users being surprised by changes.

Hachamovitch was noncommittal about what the second Platform Preview release would contain when released next month. At MIX10 we saw demonstrations of HTML5 video in a build of IE9. The version released last month, however, didn't include video support. HTML5 video is surely one of the most eagerly anticipated IE9 features. It will ship in a Preview release eventually, but we do not know when.

The Platform Preview program is still in its early stages, and this is the first time that Microsoft has developed its browser in this way; there may yet be refinements to the program as both the company and third parties learn the best way to work together, and there's no news yet of what will happen once IE9 moves into beta.

Thus far, at least, it looks like the scheme has been successful at getting third-party developers involved with IE9's development, which has to be good news for both sides.

Source: Arstechnica.com

IE9, standards, and why Acid3 isn't the priority

Microsoft's development direction of Internet Explorer 9 is unambiguous: implementing HTML5 Web standards is the name of the game, with the intent of letting developers use the "same markup" to work everywhere. As IE General Manager Dean Hachamovitch said at MIX10 this week, "We love HTML5 so much we actually want it to work."

Redmond is targeting real-world applications based on real-world data. For example, every single JavaScript and DOM API used by the top 7,000 websites was recorded. IE9 will deliver support for every API used by those sites.

That obviously gives rise to a chicken-and-egg situation—what about the APIs that developers can't currently use because of a lack of widespread support, but would like to? Beyond the top 7,000 data, Microsoft has a number of HTML5 usage scenarios that it's targeting. The company has not said much on what those scenarios are, but given the demonstrations of HTML5 video and SVG animation, it seems that these are clearly viewed as core technology for a future HTML5-powered Web.

This dedication to HTML5 does not, however, mean that Microsoft is going to devote considerable effort to, for example, the SunSpider benchmarks or the Acid3 test. As the browser develops, the scores in those tests will likely improve (it currently gets 55/100, a marked improvement on IE8's 20/100), but they're not the number one priority. Acid3 is a scattergun test. It's not systematic—you can implement a high proportion of a particular specification and not pass the test, or a much lower proportion but still pass—and though many of the features it tests are useful, that's probably not the case for everything, and it's certainly not testing the one hundred most useful HTML5 features or anything like that.

More fundamentally, there are different degrees of "supporting a standard." Some demonstrations of the highly desirable and widely demanded CSS round borders helped explain this. The IE9 Platform Preview and WebKit both purport to support CSS3's rounded borders, and the Gecko engine (in Firefox) has an extension to provide rounded borders (the extension is nonstandard, but implemented in such a way as to not interfere with standard features). Rounded borders are something that developers are particularly keen on, since without CSS support, they have to be approximated with images, which is much less flexible (you can't easily change the colour or thickness of a border if it's done with images, for example). So in terms of desirability, they rank pretty high.

Unfortunately, they don't look consistent. At all:



These are two browsers that both support a feature. But they look completely different. This has two interpretations: either one or both of the browsers is wrong, or the specification is lousy (such that both browsers are doing what the specification says, even though it's surely not what any developer would want). In general, this kind of discrepancy isn't something that a test like Acid3 will reveal. It needs systematic, thorough suites of tests that verify each individual part of the specification, and ensure that the different parts of the specifications work together.

In developing these tests, sometimes errors in the specification will be revealed. But it's also likely that errors in implementations will be revealed, even implementations that are widely perceived to "support" feature X or Y. Acid3 can't show just how much of the HTML5 standards a browser supports. It can't even tell you very much about which parts of the standards aren't supported. To do these things requires much more thorough testing.

It's for this reason that Microsoft is continuing the work it did for Internet Explorer 8. With IE8, Microsoft developed, and delivered to W3C, a huge library of CSS 2.1 tests. Systematic testing was the only way to ensure that the browser truly lived up to the demands of the specifications. So for IE9, the company is developing a new raft of tests, the first batch of which have already been submitted to W3C. Microsoft doesn't want IE9 to have the same kind of test results as other browsers presently do; a feature isn't done until all the tests pass.

A case could be made that these other browsers are perceived as more compliant than they really are; while there are certain browsers that excel in certain areas (Opera's SVG support has long been extensive), other browsers also have considerable gaps. Sure, not as big as the gaps that IE8 presently has, but substantial nonetheless. All vendors clearly have plenty of work to do before the "same markup" goal really becomes reality.

Scoring well on the SunSpider JavaScript benchmark is similarly not an explicit target for IE9. SunSpider is useful, and tests JavaScript performance in many ways, but just as real web pages aren't written like the Acid3 test, real web applications aren't written like SunSpider. Real applications do things like optimize their design so that the basic page loads quickly, and then complex activities happen asynchronously in the background. SunSpider doesn't really test this style of development, and yet this is how real applications actually work.

This doesn't make SunSpider bad, but it explains why it's not a priority. It would be a mistake to optimize specifically for SunSpider, as SunSpider is not representative of real-world usage. Developers should optimize for reality, not for specific microbenchmarks.

Microsoft wants its HTML5 support to be stable and robust. This means that Internet Explorer 9 is unlikely to support every single part of the various specifications that make up HTML5; some parts are presently too much of a moving target to be viable. Other parts may be stable, but not relevant to the scenarios that the company is using to guide its development effort. But what the company will deliver will be thorough in a way that isn't necessarily the case with other browsers. Clearly the company has an up-hill struggle if its browser is to be perceived as highly conformant with Web standards. But it's certainly heading in the right direction.

Source: Arstechnica.com