How IE8 Determines Document Mode

  • Article

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.

pie chart of what mode high traffic websites render in

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:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

A Diagram on How IE8 Determines Document 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:

  1. The Developer Tools settings override all Document Modes for pages displayed in a tab.
  2. 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.
  3. The user’s Compatibility View Settings override the Microsoft Microsoft Compatibility View List.
  4. If none of the above rules apply, the doctype determines whether the webpage renders in IE8 Standards, IE8 Almost Standards or Quirks Mode.

flow chart of IE process for determining the page doc 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.

Marc Silbey
Program Manager

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Interesting sheet you pointed to

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    March 02, 2010
    I appreciate the explanation though my interest is with XHTML. While IE does not yet support application/xhtml+xml is does support application/xml. Unfortunately IE sends a request for the doctype and since the W3C sniffs for the IE user agent, it's not found, then IE automatically throws itself in to quirks mode. To get around this I have to use HTML5's not-a-doctype-doctype (lacking version numbers make it incredibly not-forward compatible). Furthermore to get IE8 to render the page instead of displaying the XML source <?xml-stylesheet has to be used after the XML declaration. To handle backwards compatibility I first use JavaScript to check the DOM/Conditional comments to determine the browser and version, AJAX the result, and store the information in the user's session. I would greatly appreciate it if sometime in the reasonably near future if you folks could blog about getting XML to work exactly how you've explained the various rendering modes. I've seen plenty of examples one in particular where a guy blew an entire day checking serverside code and everything because one browser wasn't rendering as desired though the rest were and he was simply missing a quote. Had he used XHTML the entire page would have broken (Gecko and Presto do this correctly, IE does this correctly with application/xml, and KHTML and WebKit fail to display an error) and the error that needed to be fixed would be VERY apparent thus requiring minimal effort to fix. XHTML is also extensible so in example when the W3C removed the target attribute from anchors and the border attribute from the frameset element leaving web designers (and web developers outsourced to do web design) with XHTML one can re-extend support and still have pages validate. It's going to be VERY interesting to see how this topic evolves in IE when IE9 is finally made available to the public and I am very enthusiastic about spending time with IE9 much the same way I did with the first build of Opera 10.5!

  • Anonymous
    March 02, 2010
    Nice chart, but what about unknown doctypes like the HTML5 doctype? Also: Why are the JPEG compression artefacts in a PNG image?

  • Anonymous
    March 02, 2010
    @'John A. Bilicki III': Well, the doctype was originally not intended for versioning. That was AFAIK also the rationale behind defining the HTML5 doctype this way. And IMHO handling backwards compatibility with Javascript is a very bad idea.

  • Anonymous
    March 02, 2010
    @George Wurst Before JavaScript with DOM (not user agent) sniffing in IE6 rendered in stadards mode... http://img25.imageshack.us/img25/8097/ie6standardsjs0.png After JavaScript DOM sniffing in IE6 rendered in stadards mode... http://img442.imageshack.us/img442/1193/ie6standardsjs1.png If you know how to work with the DOM you can patch any browser by creating a new link element and loading the correct browser/version related style sheet. This can be done with 100% accuracy without the need for conditional comments. In the 29th version of my site I'm also doing this to load CSS3 stylesheets so that not a single browser has console errors while every browser that supports CSS (be it by standard or proprietary implementation) is supported...again without any console errors at the highest sensitivity to errors.

  • Anonymous
    March 02, 2010
    X-UA-Compatible?? Why not ;) <meta http-equiv="X-UA-Compatible" content="chrome=1">

  • Anonymous
    March 02, 2010
    The comment has been removed

  • Anonymous
    March 02, 2010
    @IE team, don't suppose there is a way to force IE7 to render application/xml in standards mode or is that exclusively for IE8? @Stifu People are quick to make statements and most make absolutely no effort to make inquiries. First off I don't care if someone likes my personal website. Secondly it supports themes. Thirdly the current theme is not finished so it would be pointless for me to start making a second theme now when I still anticipate making changes to the existing theme since I haven't finished porting/adding content. Fourthly: http://www.jabcreations.com/blog/?prompt=themes-editor ...and fifthly which would you fix first? An HTML error that breaks the page for people in 30% of the browser market or a style preference? Sometimes the person behind the wheel really does know where they are going...it happens more often then people think. ;-) "It's not what you look at that matters, it's what you see." - Henry David Thoreau

  • Anonymous
    March 02, 2010
    Aptana Studio does not create a transitional doctype for an empty HTML document. It uses strict.

  • Anonymous
    March 02, 2010
    Just a hint: If you want to use X-UA-Compatible in a valid html5 document, just use this snipplet: <code> <!--[if IE]> <meta http-equiv="X-UA-Compatible" content="chrome=1" /> <![endif]--> </code> The validator will not interpret it and real browsers don't need it.

  • Anonymous
    March 02, 2010
    The comment has been removed

  • Anonymous
    March 02, 2010
    Also missed in the flow chart: missed the bit about IntRAnet vs IntERnet - where you test is in a different mode than where you deploy - for added developer confusion.

  • Anonymous
    March 02, 2010
    Woopsie! Don't press the F1 key in IE! http://www.computerworld.com/s/article/9164038/Microsoft_Don_t_press_F1_key_in_Windows_XP Good old VBScript zero-day vulnerability to compromise your PC. As normal - installing ANY of the other, better browsers will ensure you don't get infected - even better still, when you upgrade your browser from IE to another browser you also get a better browsing experience!

  • Anonymous
    March 02, 2010
    DISCARD COM AND ACTIVEX NOW!!!! DISCARD IEFRAME.DLL NOW!!!! DISCARD GDI NOW!!!! DISCARD ACTIVESCRIPT NOW!!!! What we need:

  • Managed code -- means NO memory leak.

  • .NET Assemblies, not ActiveX DLLs

  • BACKWORD COMPATIBILITY IS NEEDLESS

  • DirectX, or WPF

  • DLR Microsoft has turned Visual Studio to WPF, Why not IE?

  • Anonymous
    March 02, 2010
    According to this scheme <meta http-equiv="X-UA-Compatible" content="IE=edge"> just doesn't work. Is it supposed to be so?

  • Anonymous
    March 02, 2010
    This post summarizes completely how much trouble you are causing to web developers with all the IE rendering modes (non of which on par with the other leading browsers). This is exactly why many developers have already suggested switching to an open source rendering engine like WebKit and keeping some [old] Trident version disabled by default just for "emergency cases".

  • Anonymous
    March 02, 2010
    @John: I thought you were implying the new site version was finished, but I see it was a work in progress. On the other hand, the current version (version 28 for those who weren't following) doesn't look so different, though a little better. And support for multiple themes doesn't really help. I'd rather have 1 nice theme than 10 ugly themes. I'm not saying the other themes are bad, I didn't check them out, but you'd expect one of the nicest themes to be the default, which doesn't bode well for the alternate themes. Plus, do you have stats on how many users change the site theme? Probably a minority. To be more constructive, it's mostly the purple background that hurts my eyes. And with the 29th version, also the red background. I'd use something much more subtle and homogenous.

  • Anonymous
    March 02, 2010
    @GreLI Good spot: "edge" value is missing from this diagram

  • Anonymous
    March 02, 2010
    The comment has been removed

  • Anonymous
    March 02, 2010
    Although I don't like the current situation re. Internet Explorer, standards etc, and I'm sure most web developers don't, I do think Microsoft has made the right decision by creating standards-mode and the X-UA-Compatible meta tag. I've seen quite a few comments on other blog posts like "why not use Webkit?" Unfortunately many people design their websites specifically for IE, and then there will be more anger over IE and compatibility.

  • Anonymous
    March 02, 2010
    This sums up rather well how IE 8 switches modes - it could be inferred from previous posts, but still. One that hadn't really appeared up till now it IE8 Almost Standard mode: this is actually done to reflect a small change created by Mozilla for Gecko and reflected by other browsers. It differs from Quirks mode in that there are no DOM deviations, and CSS support is pretty much equivalent to full Standards mode, but it deals with a few quirks relating to images alignment. It should also be noted that it relies on pure DOCTYPE switching, as only Transitional modes trigger it (you can't specify it through X-UA-Compatible, for example) It should be noted last that IE6/7 'Standard' mode (as opposed to Quirks) actually worked like 'almost standard'. The solution I've personally decided to adopt:

  • develop for full Standards mode: HTML 4.01 Strict or XHTML 1.0 Strict annex C
  • maybe add X-UA-Compatible for IE 'edge' - if at all (that's the only way to remove the button from IE's bar)
  • add some conditional comments for IE 7's quirks or let it degrade gracefully
  • split my CSS in two: a 'basic' stylesheet (colors and fonts only) for ALL browsers, and a CSS 2.1+ for browsers that can handle it (Gecko, Webkit, Presto, IE 7+). Yes, I've decided to put IE 6 in the 'legacy' browser category. I'm fed up with it.

  • Anonymous
    March 02, 2010
    I've got a better idea. Instead of coding to all these modes and "IE standards", code to the one  W3C standard and make life easier. Pretty much works in all modern browsers on all platforms. Something that will never happen with IE.

  • Anonymous
    March 02, 2010
    Thanks Microsoft, As usual, You are succesfull in creating this fine mess.

  • Anonymous
    March 02, 2010
    @Sam: Thanks for the note-- we'll look into the screensaver password issue. According to the folks who build the VirtualPCs, if there is a screensaver password, it's the same as the log-in credentials, which are listed in the readme.txt file that comes with the install.

  • Anonymous
    March 02, 2010
    According to the chart, IE=edge would fall through to EmulateIE8 with a Doctype and to Quirks without a Doctype. That's not true. IE=edge without a Doctype renders in IE8 Standards Mode. And I find the chart misleading: even if meta IE=8 is set, it makes a difference what Doctype is used, e.g. differences between Transitional and Standards Doctype rendering are present, e.g. http://connect.microsoft.com/IE/feedback/details/413230

  • Anonymous
    March 02, 2010
    The comment has been removed

  • Anonymous
    March 02, 2010
    Dennis--- you're missing the point. This blog post and the "UA-Compatible" modes are all about legacy IE-specific sites that don't work properly in browsers that support modern web-standards. These sites aren't compatible with FF, Chrome, Opera and Safari either. All of the IE team's work is about trying to offer compatibility with those legacy sites (so that users will happily upgrade to IE8) while offering modern compatibility with those standards-compliant sites.

  • Anonymous
    March 02, 2010
    An amazing amount of over-complication. All other browsers support 2 modes: Quirks & Standards Use a doctype if you want proper rendering. End of story.

  • Anonymous
    March 03, 2010
    The comment has been removed

  • Anonymous
    March 03, 2010
    @ vasko_dinkov > This post summarizes completely how much trouble you are causing to web developers with all the IE rendering modes (non of which on par with the other leading browsers). Vasil, I totally agree with you. A vastly complex, intricated triggering mode system (with a special terminology, pieces of code, hierarchy of rules - with exceptions - spread among webmaster, user, author, browser, managed lists, compatibility buttons, settings) does not, can not and will not succeed in the long run. Microsoft (and I've said so before in this blog) should have focused (or focused a lot more) on developing sensible tools, helpful assistive softwares, relevant MSDN documentation to help people upgrade (improve, future-proof) their websites. In doing so, Microsoft would have had a long-lasting undeniable support+collaboration from other browser manufacturers and from the W3C. Good tutorials, helpful softwares, relevant assistive coding features will always achieve more and better than a meta-tag crutch here, a senselessly unconditional backward-compatibility policy and a "whatever-your-code-has-is-fine-with/in-our-browser" policy. regards, Gérard Talbot

  • Anonymous
    March 03, 2010
    Let's say it's the future. XP and Vista are dead, but Windows 7 is still pretty common and therefore the same goes for IE8. Now, I want to create an intranet website which should be displayed in the most standard way in IE X and all of it's predecessors. So I am adding this X-UA-Compatible meta tag with it's value set to IE=N where N is a value higher than 8. According to this chart Internet Explorer 8 would then (under default settings) switch into IE7 rendering mode, am I correct?

  • Anonymous
    March 03, 2010
    @George Wurst: unknown doctypes such as the HTML5 doctype will stay in IE8 Standards Mode for IE8. @PP: You’re right that Aptana Studio creates a strict doctype for a single HTML page. It creates a transitional doctype for new Web projects. @GreLI: Thanks. Yes, <meta http-equiv="X-UA-Compatible" content="IE=edge"> does switch to IE8 Standards Mode similar to a content value of “IE=8”. @Mitch 74: Right. Mozilla explains it well - Almost Standards mode is the same as Standards Mode except in one area: how images are handled in tables. Folks can read more about Almost Standards here: https://developer.mozilla.org/en/Gecko's_Almost_Standards_Mode and here: https://developer.mozilla.org/en/Images%2c_Tables%2c_and_Mysterious_Gaps

  • Anonymous
    March 03, 2010
    The comment has been removed

  • Anonymous
    March 03, 2010
    Where does group policy fit in with this.  If an IT admin chooses to set machines in one mode using group policy and a site designer uses a header or meta tag, which takes precedent?

  • Anonymous
    March 03, 2010
    @John > don't suppose there is a way to force IE7 to render application/xml in standards mode or is that exclusively for IE8? For both IE7 and IE8 you can output a doctype from your XSLT to force standards mode rendering:    <xsl:output method="html" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"/> Keep in mind that going this route does not give you true XHTML support as XHTML is not supported by IE. What is actually happening is that the initial input is being processed by IE's XML parser, but the result of the XSLT is still fed through the HTML parser before being displayed. Thus any fix-up rules that would apply during normal HTML parsing will still be in effect. Furthermore the resulting DOM is still an HTML DOM, not an XML DOM, meaning you will encounter case-sensitivity differences in the handling of element and attribute names (among other things).

  • Anonymous
    March 03, 2010
    this is great & all but people still use ie6 or 5 because they are either on an older os or the stuff they do with it is outdated

  • Anonymous
    March 03, 2010
    Any news regarding: HTML5, SVG support, etc?

  • Anonymous
    March 03, 2010
    I'd like to recommend Microsoft dropping the bad trident framework and adapting webkit. Look at the possibilities market-wise, you could then port Internet Explorer with minimal effort to Mac and Linux as well, then MS would increase their marketshare on IE again as it would be available on all popular platforms, it would play nicely, and the w3c/developers would be happy as well.

  • Anonymous
    March 03, 2010
    The comment has been removed

  • Anonymous
    March 03, 2010
    We blogged about why and how we migrated XING's rendering in IE8 from Compatibility View to Standards View. http://devblog.xing.com/frontend/against-ie8s-compatibility-view-from-stagnation-to-standards/

  • Anonymous
    March 04, 2010
    @Tony Ross Awesome thanks! I'll test it out this weekend after I finish the project I've been working on this week. Also I know application/xml mode still handles the code as HTML to some effect though the immediate benefit is the page failing to render and displaying the error right there. When you folks finally do get XHTML working it would be nice if 'render as text/html' option was made available when an XML parse error was detected. If you folks really want to go the distance a warning for duplicated id's (including in combination with AJAX loaded content) would be something no other browser has and would be much quicker to spot in the browser then manually verifying through the validator (or very difficult with AJAX loaded content).

  • Anonymous
    March 04, 2010
    The comment has been removed

  • Anonymous
    March 05, 2010
    @Mitch 74, @Rob, @remy, @vasko_dinkov and many others > develop for full Standards mode: HTML 4.01 Strict or XHTML 1.0 Strict annex C > Instead of coding to all these modes and "IE standards", code to the one  W3C standard > All other browsers support 2 modes: Quirks & Standards Use a doctype if you want proper rendering. I fully agree with all of you. And Microsoft itself with all of its websites entirely under its control should lead, should have been promoting such code-upgrade solution by showing the example. The only real, long-lasting, forward-compatible, future-proof solutions that will work for the whole web are the ones which can work for competing web browsers as well and which would be/can be adopted and promoted by W3C itself. Valid markup code, valid CSS code, a doctype declaring a strict DTD all inside an error-free webpage is the solution Microsoft should be promoting (in its websites, in its products, in his softwares, features, extensions, etc) and preaching by showing the example. regards, Gérard Talbot

  • Anonymous
    March 06, 2010
    @Paul McKeown First off who's posts are you reading? I've made it vividly clear that sniffing the DOM and even showed two styling related properties both of which are proprietary to their respective engines. Secondly I don't use argumentative fallacies because I don't need them! You mention errors on my site which is highly likely to be WordPress. Either it was hacked because their code is absolutely horrendous or it simply failed at some point, that's not something I care about since that's not what I've been working on for the past year and a half. Thirdly serving pages as application/xml in IE even if parsed as HTML still breaks pages if there is an XML error thus worth my time versus manually validating everything page by page. While it doesn't cut the cake entirely it's still more useful then having an erroneous page render when it should not. I suggested a link, not an automatic reparse of the page. Automatically reparsing the page negates the whole point of rendering it as XHTML or IE's partial implementation.

  • Anonymous
    March 06, 2010
    The issue is how OTHER browsers determine the rendering mode. Like et al the 'standards' are subjective. Validators are'nt validated Tinto!

  • Anonymous
    March 07, 2010
    comments that were originally published (that did not violate the TOS) have been removed.

  • Anonymous
    March 07, 2010
    @whatsup: The IEBlog Comment Policy is here: http://blogs.msdn.com/ie/archive/2004/07/22/191629.aspx. Comments which do not abide by this policy are removed.

  • Anonymous
    March 08, 2010
    The comment has been removed

  • Anonymous
    March 08, 2010
    How does the browser Compatibility View Settings such as "Display all website in Compatibility View" affect things?  I have a site that specifies IE=Emulate7 with an "almost standards" doctype, and it does not work properly.  If I click "Display all website in Compatibility View" it does work.  What does that setting actually do?

  • Anonymous
    March 08, 2010
    @Dazza: The proper directive is IE=EmulateIE7 http://blogs.msdn.com/ie/archive/2008/06/10/introducing-ie-emulateie7.aspx

  • Anonymous
    March 08, 2010
    @EricLaw - Thanks, but that was just a typo. What I mean is, my site does not work when Browser Mode is IE8 and and Document Mode is IE7 Standards Mode.  However if I change the Browser Mode to IE8 Compatibility View using either the developer tools or the "Display all website in Compatibility View" setting it displays correctly.  I have tried IE=EmulateIE7 and IE=7 which both trigger IE7 document mode correctly. There seems to be little documentation on Browser Mode, specifically the differences between IE8 and IE8 Compatibility View Browser Modes.  The blog entry seems to suggest that setting the document mode explicitly overrides the users Compatibility View settings, but the relationship between Browser Mode and Docuement Mode and Compatibility View settings seems to be more complex than that.

  • Anonymous
    March 08, 2010
    @Dazza: That suggests that your site is possibly using the User-Agent string to change behavior. Is the site public so I could have a quick look?

  • Anonymous
    March 08, 2010
    @ieblog The site is not public access.  I think you are correct.  We use a third party javascript widget for data grids and it looks like it uses User-Agent string to determine behaviour, so the widget will work in IE8 "mode" regardless of the document mode.  Not sure I can work around that easily.

  • Anonymous
    March 08, 2010
    @JABIII Actually, just looked up jQuery support for browser sniffing.  It is deprecated as of version 1.3, vid. http://docs.jquery.com/Release:jQuery_1.3 .  Of course, it bases its sniff on UA string, but the principle remains, and one they themselves state: use feature detection. If you really want to get into doing things the right way, can I recommend a look at: http://peter.michaux.ca/articles/feature-detection-state-of-the-art-browser-scripting , which is a fabulous, if rather difficult article.

  • Anonymous
    March 10, 2010
    I tried using: <meta http-equiv="X-UA-Compatible" content="IE=Edge"> ... to get rid of the compatibility button, which worked fine, but when I added "chrome=1", e.g: <meta http-equiv="X-UA-Compatible" content="IE=Edge;chrome=1"> ... IE failed to remove the button. I'd like to use Chrome Frame if it's available, but would also like IE to remove the button - is this possible with the method above, or any other method??

  • Anonymous
    March 12, 2010
    The comment has been removed

  • Anonymous
    March 13, 2010
    Internet explorer 8 ISN'T work in Windows server 2003 :( ,,, i can't install that =( .. only work in Server 2003 SP2, why?? :S ..