OK, so the title is mine, but you can see here how the defacto standard that was IE4/5/6 meant that people thought IE7 would live by the same rules.  If you care about "standards based websites" then the IE team blog on compatibility is a must for you.

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.

IEBlog : Compatibility and IE8

ttfn

David