If you’re not a web developer, the details of this blog post probably aren’t all that interesting for you. I’d like you to know that we’re building IE8 for many different customers (consumers, web service providers, independent software vendors, enterprises, web developers, and others), and we’ll cover more details of the non-developer oriented work (e.g. user experience, reliability, security, etc.) in other posts in the future, after MIX.

While web developers will immediately recognize what Acid2 means, I want to step back and offer some context for other readers of this blog who may not be familiar with web standards. Briefly: Acid2 is one test of how modern browsers work with some specific features across several different web standards.

At first glance, this test seems simple. I think it actually offers a view into the subtle and complex world of web standards in a number of ways. Showing the Acid2 page correctly is a good indication of being standards compliant, but Acid2 itself isn’t a web standard or a web standards compliance test. The publisher of the test, the Web Standards Project, is an advocacy group, not a web standards defining body.

When we look at the long lists of standards (even from just one standards body, like the W3C), which standards are the most important for us to support? The web has many kinds of standards – true industry standards, like those from the W3C, de facto standards, unilateral standards, open standards, and more. Some standards like RSS or OpenSearch lack a formal standards body yet work pretty well today across multiple implementations. Many advances in web technologies, like the img tag, start out as unilateral extensions by a vendor. The X in AJAX, for example, has only started the formal standardization process relatively recently. As some comments have pointed out, CSS 2.1, one of the key standards that Acid2 exercises, is not “finalized” yet. Different individuals have different opinions about different standards. The important thing about the Acid2 test is that it reflects what one particular group of smart people “consider most important for the future of the web.”

The key goal (for the Web Standards Project as well as many other groups and individuals) is interoperability. As a developer, I’d prefer to not have to write the same site multiple times for different browsers. Standards are a (critical!) means to this end, and we focus on the standards that will help actual, real-world interoperability the most. As a consumer and a developer, I expect stuff to just work, and I also expect backwards compatibility. When I get a new version of my current browser, I expect all the sites that worked before will still work.

With respect to standards and interoperability, our goal in developing Internet Explorer 8 is to support the right set of standards with excellent implementations and do so without breaking the existing web. This second goal refers to the lessons we learned during IE 7. IE7’s CSS improvements made IE more compliant with some standards and less compatible with some sites on the web as they were coded. Many sites and developers have done special work to work well with IE6, mostly as a result of the evolution of the web and standards since 2001 and the level of support in the various versions of IE that pre-date many standards. We have a responsibility to respect the work that sites have already done to work with IE. We must deliver improved standards support and backwards compatibility so that IE8 (1) continues to work with the billions of pages on the web today that already work in IE6 and IE7 and (2) makes the development of the next billion pages, in an interoperable way, much easier. We’ll blog more, and learn more, about this during the IE8 beta cycle.

Now, with all that context, I’m delighted to tell you that on Wednesday, December 12, Internet Explorer correctly rendered the Acid2 page in IE8 standards mode. While supporting the features tested in Acid2 is important for many reasons, it is just one of several milestones for the interoperability, standards compliance, and backwards compatibility that we’re committed to for this release. We will blog more on these topics. Here’s a relevant video.

For IE8, we want to communicate facts, not aspirations. We’re posting this information now because we have real working code checked in and we’re confident about delivering it in the final product. We’re listening to the feedback about IE, and at the same time, we are committed to responsible disclosure and setting expectations properly. Now that we’ve run the test on multiple machines and seen it work, we’re excited to be able to share definitive information.

While blog posts and links to videos are a good start, publicly available code is even better. We will have a lot more information available at sessions at MIX08 and will release a beta of IE8 in the first half of calendar 2008.

Dean Hachamovitch
General Manager

source: MSDN Blogs - Blogs