This post describes how IE8 determines what Document Mode
such as Quirks or Standards Modes
to use for rendering websites. This topic is important for site developers and consumers.
Itís related to the Compatibility View List that we recently updated
. This list is down by over 1000 websites, from over 3100 to just over 2000, since IE8 released last March. As we work with site developers and standards bodies, weíre excited to see the sites that need to be on the Compatibility View (CV) List continue to go down. Data-driven Design
Before we dig in to the design details, I want to share some of the data we use to design the compatibility experience.
When looking at the doctype
and X-UA-Compatible meta tag and header
on thousands of high traffic websites worldwide such as qq.com, netlog.com and those on the initial CV List
- 26% specify Quirks such as amazon.com, tworld.co.kr, and unibanco.com.br.
- 41% specify a Transitional doctype that puts them in Almost Standards Mode.
- 14% have already added an X-UA-Compatible meta tag or HTTP response header to render in IE7 Standards Mode.
Hereís why this makes sense; many high traffic websites want to render in as many browsers as possible, which is why they write for Quirks. Many websites have pages written specifically for IE7 and many web authoring tools such as Aptana Studio
and Expression Web
specify the Transitional doctype by default:
Thinking in terms of web-scale, there are billions of pages written specifically for either Quirks, IE7, Almost Standards, or the latest Standards. IE needs to support all of these web platform variations to ensure that our broad, world-wide, user-base has the best experience.
With this data in hand, we designed IE8 with a few principles in mind:
A Diagram on How IE8 Determines Document Mode
- Render websites in the most standards compliant way by default. As stated in previous posts, weíre committed to interoperability, which means rendering websites in the most standards compliant way possible by default.
- Users expect the web to just work in IE. A small set of users will tinker to get websites that expect and work best in IE7 Standards Mode to work in IE8ís more standards-compliant default mode. For everyone else, IE8 includes Compatibility View Settings.
The best experience here is one that works automatically as the web developer intended. This is why we created the Compatibility View List. Itís also important to give users the ability to fix websites that arenít on the list yet through the Compatibility View button.
- Web developers are in control of how their content renders. The X-UA-Compatible meta tag and header override IE and user settings. They also provide web developers with fine-grain control over how each webpage renders in IE.
For example, some websites have pages written for Quirks and others for IE7 Standards. When IE receives an X-UA-Compatible header with an EmulateIE7 value from servers, it renders each page in the appropriate Quirks or IE7 Standards Mode.
- Give web developers tools and time to help transition their content to IE8 Standards. IE8 introduced the X-UA-Compatible meta tag and header to provide web developers time to transition their websites to IE8 Standards. As mentioned above, many websites have already used this mechanism to specify that their content should run in IE7 Standards Mode.
Given the above principles, there are four rules that you can remember about how IE handles doctype, X-UA-Compatible meta tag and header, Developer Tools, and Compatibility View Settings. These rules follow the diagram below from top to bottom:
- The Developer Tools settings override all Document Modes for pages displayed in a tab.
- The X-UA-Compatible meta tag and then header override Compatibility View Settings and the doctype unless the X-UA-Compatible value is EmulateIE7 or EmulateIE8.
- The userís Compatibility View Settings override the Microsoft Microsoft Compatibility View List.
- If none of the above rules apply, the doctype determines whether the webpage renders in IE8 Standards, IE8 Almost Standards or Quirks Mode.
Compatibility and interoperability are complex. To reduce complexity for developers and users alike, we would love to see websites transition from legacy browser modes. We respect that the choice of mode is up to the site developer. Weíre excited to work with sites and standards bodies to continue improving IEís
implementation of interoperable standards.
Many thanks to Jesse Mohrland for verifying the diagram.