Compatibility and IE8
Download this page and then do something to make Chris' text flow among the images. You can explain how you did this by filling in the DIV at the bottom of this page.
In IE7 we made a lot more changes to improve IE’s standards compliance, particularly with CSS. We limited these behavior changes to IE’s “standards mode” only, and we expected that this would help limit compatibility problems as it had in the past. Unfortunately, and somewhat surprisingly to us, this wasn’t true; many of those changes made IE incompatible with content that was already part of the web. It turned out by the time IE7 shipped in late 2006, roughly half of the top 200 US web sites were in “standards mode”. Many of those sites had been “opted in” to standards mode by a tool that generated their content; many of them had probably been hand-coded by someone who was trying to do the right thing, and make their HTML code valid according to the W3C. Regardless, users of those sites expected them to keep working the same, even when they downloaded a new version of IE. Unfortunately, that didn’t happen.
But wait, a lot of people say at this point, why isn’t this a problem for Firefox, or Safari, or any other browser? The answer is that developers of many sites had worked around many of the shortcomings or outright errors in IE6, and now expected IE7 to work just like IE6. Web developers expected us, for example, to maintain our model for how content overflows its box, even in “standards mode,” even though it didn’t follow the specification – because they’d already made their content work with our model. In many cases, these sites would have worked better if they had served IE7 the same content and stylesheets they were serving when visited with a non-IE browser, but they had “fixed their content” for IE. Sites didn’t work, and users experienced problems.
In short, there was an expectation that even under standards mode, IE would keep working the same way. Because sites expected IE6 behavior, the DOCTYPE switch failed to protect compatibility in the real world when we changed behavior under standards mode to become more compliant. We realized that “Don’t Break the Web” should really be translated to “Don’t change what developers expect IE to do for current pages that are already deployed.” (Of course, for content that is developed to a later standard that isn’t deployed yet, you can expect different things.)
With this painful and unexpected lesson under our belt, we worked together with The Web Standards Project (in the WaSP-Microsoft Task Force) on this problem. I can’t give them enough credit for this work; it’s tough to step into the shoes of a browser vendor that ships to half a billion users to figure out what the best thing to do is, when you really just want to sit down and write code to the standards. We started from a simple statement of “enable (and encourage) interoperable web development, but don’t force IE to break pages that work properly in IE today.” I think we all want to converge to a world where a web developer doesn’t have to spend much time at all testing and recoding their site for different browsers. At the same time, we can’t break the web experience on current sites for users like my mom, even for as good a reason as improving standards compliance. With all the great styling and layout changes we’re working on in our new engine for IE8 to be much more standards compliant, that’s a lot of potential breakage. (More details in the near future, but the Acid2 announcement gives you some idea.)
We realized that the model for web development was really “write to the standard, then test against and fix problems in the most popular browsers.” This meant that the web developer had one crucial piece of information we could make use of – what version of IE they had tested against, and after much discussion in the WaSP-MS task force, we ended up with a <meta>-based “opt-in to the browser version I tested with” strategy.
Aaron Gustafson, one of the members of the WaSP-Microsoft Task Force wrote an article detailing where we ended up that was posted on A List Apart today; I highly recommend reading it for a different perspective. I’ll summarize, though, that:
1. “Quirks mode” remains the same, and compatible with current content.
2. “Standards mode” remains the same as IE7, and compatible with current content.
3. If you (the page developer) really want the best standards support IE8 can give, you can get it by inserting a simple <meta> element. Aaron gives more details on this in his article.
We believe this approach has the best blend of allowing web developers to easily write code to interoperable web standards while not causing compatibility problems with current content. We also think this approach allows developers to opt in to standards behavior on their own schedule and as it makes sense to them, instead of forcing developers into a responsive mode when a new version of IE has different behavior on their current pages. I’m excited by all the standards work we’re doing in IE8; I’m even more excited that we won’t cause a lot of compatibility problems for our users and web developers.
Chris Wilson
IE Platform Architect