Compatibility and IE8
In Dean’s recent Internet Explorer 8 and Acid2: A Milestone post, he highlighted our responsibility to deliver both interoperability (web pages working well across different browsers) and backwards compatibility (web pages working well across different versions of IE). We need to do both, so that IE8 continues to work with the billions of pages on the web today that already work in IE6 and IE7 but also makes the development of the next billion pages (in an interoperable way) much easier. Continuing Dean’s theme, I’d like to talk about some steps we are taking in IE8 to achieve these goals.
I’ve been on the IE team for over a decade, and I’ve seen us apply the “Don’t Break the Web” rule in six different major versions of IE in different ways. In IE 6, we used the DOCTYPE switch to enable different “modes” of behavior to protect compatibility. When we released IE 6 in 2001, very few pages on the web were in “standards mode” (my team ran a report on the top 200 web sites at the time that reported less than 1%) – few people knew what a DOCTYPE was, and few tools generated them. We used the DOCTYPE switch in IE6 to change the box model to comply with the standards and enable developers to opt-in to the new behavior. We’d already seen so much content written to IE5.x’s non-standard interpretation of the CSS2 spec that we couldn’t change it without causing a slew of problems.
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:
- “Quirks mode” remains the same, and compatible with current content.
- “Standards mode” remains the same as IE7, and compatible with current content.
- 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