We’ve said a lot about our approach to website compatibility in general and the Compatibility View feature in particular. But because we've shared this information across multiple blogs and sources, I’d like to quickly recap what we’ve previously announced in summary form and provide links to additional content / reading as necessary.
IE8 Standards by Default
Going into IE8 Beta 1, the Internet Explorer team demonstrated its commitment to interoperability and web standards by announcing that IE8 will interpret web content in its most standards compliant way - by default. This means viewing pages in IE8 Standards Mode isn’t opt-in, it’s the way the product works out of the box. We believe this to be the right decision as it’s forward looking and supports developers and designers as they create the next billion web pages. We want to both respect the site author’s intent AND create a positive end user experience. We've reinforced our commitment at subsequent releases (Beta 2, Release Candidate) and still believe "standards by default" to be important.
Compatibility
There’s a short term consequence to the “standards by default” decision, namely compatibility problems with existing pages. Many of today’s web pages, even pages written “to the standards”, expect the old, less interoperable behavior from IE and, as a result, don’t work perfectly in IE8’s standards-by-default mode. Here’s what we’ve done to address this problem –
Compatibility View
Compatibility View first appeared in Beta 2 builds. We refined the experience further in the Release Candidate build by incorporating feedback received during the Beta. Most notably, Compatibility View list updates were added at that time.
A deeper description of the feature set can be found in previous posts. Below I’ve tried to summarize important points and/or aggregate information that was sprinkled across several sources –
There are two cases where select Compatibility View features come pre-configured as part of IE's "smart defaults". For one, sites that map to the Intranet zone display in Compatibility View by default. This allows IE8 to be most compatible with line-of-business applications that expect IE7 behavior. (This can of course be changed by the user as well as configured via Group Policy.) Another case of "smart defaults" is the setting ‘Automatically recover from page layout errors with Compatibility View’. The topic deserves its own deeper handling as a stand-alone blog entry, but I’ll just quickly state here that the setting makes an otherwise completely unusable page usable again. When the IE Layout Engine encounters an unrecoverable error during page processing it shows a blank page rather than allowing the user to interact with a corrupt or otherwise obviously incorrectly displayed page. In such a case, IE attempts to reload the page temporarily (read: until you close and re-open IE) in Compatibility View based on the setting mentioned above. We believe that showing a page the way IE7 would have is a better user experience than showing no content at all. We’re working hard to fix known causes of these unrecoverable errors in our layout engine and we get Watson data for the rare occasions when they do happen.
Whether or not developers are able to update their sites to support IE8 Standards, people who use IE8 expect that the web will keep working. They want *both* interoperability and compatibility. The Compatibility View list feature attempts to provide just that for the web’s most trafficked sites.
I’ve seen a few blog posts of late that express concern over the compatibility list feature, namely that it will encompass a zillion sites and live on in perpetuity (and thus negate our standards-by-default promise). I want to take a minute to speak directly to that concern. First, the list is only enabled by user choice - it isn't active by default. Second, the purpose of the list is to ensure that IE users are given the option to have a great experience on the web's most trafficked sites. Research data shows that the percentage of unique visitors (reach) and average number of minutes users spend on a page are skewed considerably towards very popular internet destinations like microsoft.com, facebook.com, and cnn.com. Having a great experience on these domains means our users have a great experience with IE8. There’s a finite number of such popular sites, and it’s on the small side. Third, we use customer feedback via product telemetry, bug reports, Report a Webpage Problem, etc… as inputs to a system for generating the list. This is real customer data that relates to real-world compatibility experiences; it's a very accurate measure of exactly how IE users are experiencing these high traffic sites. Next, we view list updates as a short term compatibility option and have committed to regularly revisit the need to ship the list at all. We recognize that it takes time for organizations to update their sites for Internet Explorer's transition to better web standards. This update timeline can vary greatly by organization. The feedback we've received so far has been overwhelmingly positive as many see it as a way to help organizations concentrate on supporting IE8 Standards in the long term. Lastly, we contact the site owner (as identified by WHOIS) for each domain on the list to let them know about the experience that IE8 users are having on their site and to give them removal steps (if they so choose). We ship regular updates to the list on the same schedule as, but separate from, IE security updates, in an effort to make the process predictable to both websites and IT organizations.
Recap
I’ve seen come confusion in the blogosphere regarding the Compatibility View feature set and I sincerely hope the above helps to clear it up. As always, if you still have questions, please feel free to post them in the comments and I’ll try to answer them.
Scott Dickens Program Manager
Update 2:16 - removing duplicate paragraph.Update 2/17 - minor text correction.