The information published in this post is now out-of-date and one or more links are invalid.—IEBlog Editor, 20 August 2012
We’ve had more than a few comments suggesting that IE works too hard at backwards compatibility, and we cater to those people who “don’t code their pages correctly”, or people who otherwise “didn’t do things the right way”. These comments frequently go on to suggest that we (the IE team) should use our market position to “force people to fix their broken stuff”.
I’d like to explain why we so adamantly disagree with that position, and why we work so hard at backwards compatibility.
We feel it is vitally important for web sites and applications that worked with yesterday’s IE work with today’s IE, and continue to work with tomorrow’s IE. We feel this is a deeply held expectation by the millions of IE users.
In XPSP2, we sometimes had quite a struggle balancing the need to increase the security of the browsing experience and platform with living up to our compatibility responsibility.
Part of this struggle was because we have an incredible number of different users and developers using IE in many different ways, and we have to take all of those customers into consideration when developing and testing changes to our code base, especially security changes. Any change we make, be it a hot fix request from one particular customer, a security fix based on investigation external or internal, a fix to an issue reported through Windows Error Reporting, or a simple bug fix, could have potentially far ranging consequences throughout our user base.
Does all this mean we can’t (or shouldn’t) make changes? No, not at all. We can and will continue evolve IE towards better functionality, security, and stability. But it does mean that we need to move carefully with deep consideration of the impact of our changes.
We may take steps to mitigate compatibility issues with changes we want to make. For example, in Internet Explorer 6 we introduced the strict doctype to allow us to improve our CSS implementation without impacting existing HTML pages. We expect to use similar techniques for future enhancements where we might affect existing content.
One of the most difficult tradeoffs is when a change pits one set of customers against another set. Make the change, and N millions of customers are happy and K millions of customers are unhappy. Don’t make the change, and the N and the K reverse. As we were making changes for IE for XP SP2, when we found ourselves back against the wall like that, we chose security over compatibility. And if you read the industry press, you can guess how many N millions of customers are happy with our choices and how many K millions of customers are unhappy about it.
With Windows XP SP2 we had an open beta program so that we could make changes to improve compatibility based on customer feedback, and we reached out to developers to help them get compatible when security considerations warranted causing some level of incompatibility. In the end, we believe that with XP SP2 we have the balance about right.