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.
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 –
- We’ve evangelized all of the great work the team has done to better support web standards in IE8 (like CSS 2.1, a better Document Object Model, ARIA, and cross-domain requests (XDR) and cross document messaging (XDM) and our start on HTML5 support) and asked web developers to update their existing pages to support IE8 Standards mode.
- We’ve evangelized use of the X-UA-Compatible tag to websites unable to update to support IE8’s Standards mode. The tag allows a web author to declare the exact standards mode behavior for which their website works best – IE8 Standards (again, the default when no header is present) or IE7 Standards. For example, using the value ‘IE=EmulateIE7’ causes IE8 to display a website “as IE7 would have”.
- We’ve provided end-user and corporate / IT mitigations to the website compatibility problem under the umbrella term ‘Compatibility View’. ‘Compatibility View’ allows IE8 users to have a great experience even when visiting websites that haven’t yet performed either of the above two steps. It also helps IT organizations preserve compatibility with the large number of line-of-business websites that are Internet Explorer 7 capable today.
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.
- When installing, users can choose to use the Compatibility View list (and thus opt-out of IE8’s standards-by-default configuration). Users have to choose to use the Compatibility View list, and receive updates for it – it’s not on by default. Users can also “click the button” that places a site into Compatibility View. Both actions involve users exercising choice to override IE’s defaults.
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.
- Site owners are *always* in control of their content. By default, Internet Explorer uses DOCTYPE switching to determine Quirks v. Standards mode (again, Standards mode maps to IE8 Standards by default). Site owners can choose to use the X-UA-Compatible tag to be absolutely declarative about how they’d like their site to display and to map Standards mode pages to IE7 Standards. Use of the X-UA-Compatible tag overrides Compatibility View on the client.
- Compatibility View list updates make sure IE8 customers have a great experience with highly trafficked sites that have not yet fully accomodated IE8’s better implementation of web standards.
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.
- Sometimes the Compatibility View button isn’t displayed. The button is located on the address bar next to the ‘stop’ and ‘refresh’ buttons. There are a few cases where there’s no action for a user take and, thus, the Compatibility View button will not show:
- If you’re viewing an internal-to-Internet Explorer page (such as about:InPrivate)
- If you’re viewing a page that has declared it’s “ready” for Internet Explorer 8 through use of the versioning <META> tag / HTTP header (it doesn’t matter if this tag triggers Quirks, IE7 Standards, or IE8 Standards, the button won’t be displayed)
- If you’re viewing an intranet page and you have the ‘Display intranet sites in Compatibility View’ checkbox selected
- If you’re viewing any webpage and you have the ‘Display all websites in Compatibility View’ checkbox selected
- If you’re viewing a webpage that is included on the Microsoft-supplied compatibility view updates list and you have the ‘Include updated website lists from Microsoft’ checkbox selected
- If you’ve toggled either the ‘Document Mode’ or ‘Browser Mode’ settings via the Developer Toolbar
- Compatibility View and the X-UA-Compatible tag are not equivalent. Compatibility View is something you do on the client. It affects three things: the User Agent string, the Version Vector (used in evaluation of conditional comments), and what mode DOCTYPEs that trigger Standards map to – IE8 Standards or IE7 Standards. The X-UA-Compatible <META> tag / header is something you use in page content / server-side and, when present, completely overrides Compatibility View settings on the client. It affects two things: the Version Vector and what mode DOCTYPEs that trigger Standards map to. It can’t affect the UA string as it’s already too late to change that – the client’s already made the GET request to the server (and it contains a UA string). What this means to developers is that if your site pivots on the User Agent string, adding just the X-UA-Compatible tag (to cause IE8 to display your site in IE7 Standards mode) won’t make your website compatible – you’ll also need to update your User Agent string detection logic as well.
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.
Update 2:16 – removing duplicate paragraph.
Update 2/17 – minor text correction.