How IE8 Determines Document Mode

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, and those on the initial CV List,

  • 26% specify Quirks such as,, and
  • 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" "">

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 (59)
  1. Anonymous says:

    would you please give it up? your browser sucks. but thank you by the way, cos at least i can do this:

    <!–[if IE]>

    <style type=’text/css’>

    * { display: none; }



  2. Anonymous says:

    Interesting sheet you pointed to

  3. Anonymous says:

    @John A. Bilicki III – I think we would all take your comments *much* more seriously if we didn’t see your "professional" website and cringe.

    1.) Black backgrounds are usually only used in nightclub and pr0n sites.

    2.) The drop arrows in your menu are all mis-aligned

    3.) The purple swirling background is too distracting

    4.) Your signin form looks disabled because you made the fields gray

    5.) Why is your RSS icon blurry?

    6.) There is overflow on your right panels but no scrollbar – what gives?

    7.) Best of luck with the donation links

    8.) 7 months in Alpha 3 stage? – for a website? seriously dude – give up on the versioning.  Its a website – not an application

    9.) Centered menu text looks tacky

    10.) Honestly my eyes want to bleed looking at that site.  It does your career portfolio no justice if you are as tuned into web technologies as you seem. 100% pure constructive criticism… Rip your site apart and rebuild it from scratch making it look *nothing* like it does right now… will make you/your site look seriously professional.

    Take a look at a site like

    They manage to use a dark background yet make the site clear and easy to read. Its clean with lots of padding and no useless cruft filling up space.

    Eric Martin’s site (again, dark background, still works)

    text copy vs. background has contrast yet isn’t harsh.

    If you want lots of content you can still do it cleanly.  check out Kreative News:

    It has lots of info – but no fluffy stuff.

    Its tough to hear criticism but I’m sure that you’d like to make the best impression possible.  Spend a week or two designing a new layout from scratch – see what you can come up with.  Even provide a link from your existing site and request feedback.  I’m sure you’ll find that your audience will appreciate the changes.

    Best of luck!

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

  5. George Wurst says:

    Nice chart, but what about unknown doctypes like the HTML5 doctype?

    Also: Why are the JPEG compression artefacts in a PNG image?

  6. George Wurst says:

    @’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.

  7. @George Wurst

    Before JavaScript with DOM (not user agent) sniffing in IE6 rendered in stadards mode…

    After JavaScript DOM sniffing in IE6 rendered in stadards mode…

    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.

  8. Anke says:

    X-UA-Compatible?? Why not πŸ˜‰

    <meta http-equiv="X-UA-Compatible" content="chrome=1">

  9. Stifu says:

    @John: I don’t mean to troll or anything, but your site looks horrible. And the fact it’s the 29th version makes me an even sadder panda. πŸ™

    You may know the "web" part of "web design", but now it’s time to spend more time on the second word.

    Disclaimer: I know my site design also sucks, so no need to point that out. It’s not the 29th version though, more like the 4th.

  10. @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:

    …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

  11. PP says:

    Aptana Studio does not create a transitional doctype for an empty HTML document. It uses strict.

  12. Oliver says:

    Just a hint:

    If you want to use X-UA-Compatible in a valid html5 document, just use this snipplet:


    <!–[if IE]>

    <meta http-equiv="X-UA-Compatible" content="chrome=1" />



    The validator will not interpret it and real browsers don’t need it.

  13. sam says:

    The part I love most about this post, is that it was released ONE FULL YEAR after the browser shipped!

    Not having this as a reference is one of the reasons that developers were despising IE, trying to get their sites to render properly in IE6, IE7 and IE8.

    Developers install IE8 and test in it and pseudo-IE7 but then hit a wall when they realize that the compat mode isn’t exactly IE7 (there’s many differences) and they still need to test in IE6.

    So we fire up Virtual PC to test, download an IE6 and IE7 image and test away.  Curse blue murder when we discover that the IE7 image has the screensaver set to lock-via-password after a 10min idle time! (we don’t have the password!)

    Ok, reboot and reset the screensaver.

    Ok, so test in virtual IE6 and virtual IE7 and real IE8 after building and debuging in Firefox or Chrome.

    phew what a painful process.

    What is worse of course is that Mix10 is around the corner and IE9 will likely be showcased.

    What new modes will IE9 bring? This testing matrix is becoming a bit nuts!

    I can’t speak for everyone, but I certainly ***DO NOT WANT*** to see any eye-candy new features (web slices,accelerators, etc.) in IE9

    Dealing with yet another rendering engine (even though I WANT IT) will be hard enough.

    More importantly we are expecting proper DOM nodeTypes, Event listeners, etc. and (quite frankly) will be quite disappointed if IE ships without them and instead includes a bunch of useless fluff.

  14. sam says:

    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.

  15. garmon says:

    Woopsie! Don’t press the F1 key in IE!

    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!

  16. infinte says:





    What we need:

    * Managed code — means NO memory leak.

    * .NET Assemblies, not ActiveX DLLs


    * DirectX, or WPF

    * DLR

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

  17. GreLI says:

    According to this scheme <meta http-equiv="X-UA-Compatible" content="IE=edge"> just doesn’t work. Is it supposed to be so?

  18. vasko_dinkov says:

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

  19. Stifu says:

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

  20. hAl says:


    Good spot: "edge" value is missing from this diagram

  21. Paul McKeown says:

    @John B

    >>>I appreciate the explanation though my interest is with XHTML. >>>

    Well, exactly.  It seems that even you appreciate that your gem of (off!) wisdom is off-topic.

    And html5’s designers deliberately chose not to version the doctype, so that we could all concentrate on writing for the web, using progressive enhancement, rather than wasting our time targeting specific browser versions and their quirks.  Perhaps idealistic, time will tell, but again irrelevant to the discussion of IE8’s Document mode.

    Javascript browser sniffing is a bit dubious at the best of time, but if you wish to target IE versions from 5 to 8 (and presumably 9 too) use conditional comments. If you don’t want them in your x/html you can use conditional comments in jscript too:



     @if (@_jscript_version > 5.7)

          // IE8

     @elif (@_jscript_version == 5.7)

          // IE 6 or IE 7

          // split using test for window.XMLHttpRequest

     @elif (@_jscript_version == 5.6)

         // IE 6

     @elif (@_jscript_version == 5.5)

         // IE 5.5


         // IE 4 or 5



    CODE ENDS>>>

    If you were to combine this with tests for XMLHttpRequest, you can detect IE versions from 4 to 8.  Again I fail to see how this is relevant to the subject matter at hand, here.

    This nonsense about a missing quote, ever tried just validating the document?  Might save us all from hearing this anecdote for the nth time.  Certainly not the real benefit of xhtml over html, there are many, but documents failing all over the web would be a disadvantage, rather than an advantage.  Again IRRELEVANT to this topic.

    This xml-stylesheet hack that you are using, well sorry to tell you, IE appears to process the document as xml, as it tests for well-formedness, but this appearance is actually only skin deep, as it doesn’t really process the document further as xml, but as html.  There are many subtle ways that this can be seen.  The trick is not recommended.  Again IRRELEVANT.


    A troll irrelevant to this blog item.

    Microsoft – thanks for your interesting blog post.  Keep them coming!

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

  23. Mitch 74 says:

    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.

  24. Rob says:

    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.

  25. Vijay says:

    Thanks Microsoft,

    As usual, You are succesfull in creating this fine mess.

  26. EricLaw [MSFT] says:

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

  27. Ingo Chao says:

    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.

  28. Dennis says:

    Interesting. But instead of saying that there are sites incompatible with IE8, MS should say that IE8 is not compatible with  xx% of sites.

    Even though MS is trying to improve IE, it still is the most non-standard-following browser, incompatible with tons of things that work beautifully with FF, Chrome, Safari, Opera.

    Why can’t MS just use WebKit to power IE?

  29. Matt says:

    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.

  30. remy says:

    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.

  31. @ Marc Silbey [MSFT]

    1- Your blog post mentions "Document mode" but it makes no attempt to explain/define "Browser mode" and its distinctiveness/uniqueness from "Document mode".

    2- Last year, there were not a single word about "Almost standards mode" in IE blog. Today, you’re mentioning this mode.

    3- Last year and before, "Strict mode" was defined as IE7 when triggered in standards compliant rendering mode by the doctype decl. switch. Now, this "Strict mode" terminology has just vanished in your post. I can assure you that "Strict mode" has been used, reused by many of your colleagues (Chris Wilson for one) and often repeated at MSDN. I will find excerpts and quote them if we need to go this far. mode ie7&ac=1

    4- No word, no reference, nothing about

    meta http-equiv="X-UA-Compatible" content="IE=IE7"


    meta http-equiv="X-UA-Compatible" content="IE=IE8"

    5- A webpage without a doctype declaration (or one which normally triggers quirks mode: e.g. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> being a very popular doctype decl. being used in the last decade by WYSIWYG HTML editors) will be rendered with web standards compliant rendering engine if the meta-tag (meta http-equiv="X-UA-Compatible" content="IE=8") triggers it. A pure "break-the-web", ill-advised decision. Microsoft IE Team was warned fair and square in public about such misguided and wrong design decision. It’s still time/never too late to correct/repair a grave design error. Such X-UA-Compatible meta-tag triggering system should have been compatible with the doctype switching system in the first place.

    6- Your post (chart & explanations) has no word on conditional comments and how they affect rendering. There are people who use and have been using such Microsoft proprietary feature in their websites/webpages.

    7- "we’re excited to see the sites that need to be on the Compatibility View (CV) List continue to go down."

    Are there any microsoft-controlled websites still on that compatibility list?

    8- "(…) Expression Web specify the Transitional doctype by default"

    Is the latest Expression Web version specifying/declaring a strict doctype by default? Is the latest Expression Web still specifying the IE engine as CSS setting instead of CSS 2.1?

    9- "many high traffic websites want to render in as many browsers as possible, which is why they write for Quirks."

    The first thing that MSDN articles and IE team people should be saying loud and clear to those high traffic websites is that if they want to render accordingly, as expected in as many browsers as possible, then they should write for standards compliant rendering mode, with error-free (markup and CSS code) webpages. That was true 10 years ago, that’s true today and that’s still be true in 10 years from now.

    10- "Give web developers tools and time to help transition their content to IE8 Standards."

    I am all for better software tools (to shepperd transition), useful/relevant assistive tools, proactive web standards compliant edition tools, ATAG 1 tools but Microsoft has not provided any worth mentioning in the last 2 years.

    11- "Render websites in the most standards compliant way by default."

    With so many forks, nodes in that macaroni-like diagram, it’s pretty obvious that such "most standards compliant way by default" commitment becomes pretty diluted, watered down.

    Your diagram has holes, obscur/silent areas.

    is more complete and

    is more trustable

    12- Your post and diagram do not even mention the preceding SGML comment bug affecting rendering mode. Will IE9 fix bug 354956 and bug 382800?

    regards, Gérard Talbot

  32. @ 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

  33. George Wurst says:

    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?

  34. MarcSil [MSFT] says:

    @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:‘s_Almost_Standards_Mode and here:

  35. @Stifu The new version does not depend on third party software save the local search engine. Again I’ll reiterate my point in an analogy, IE did not get SVG in IE8, IE8 had a massive amount of work done in regards to CSS. Since I’ve been removing third party dependencies one could deduce that I’m more concerned about my own modules working correctly.

    @Paul McKeown With XHTML one does not need the validator save for minor issues such as duplicate id’s which isn’t an issue with good coding practices such as using very specific/unique names. When you validate your page as HTML6 the validator will have to guess if you’ve written your page in HTML5 or HTML6 as a versionless anything inherently declares that it is the final version what it declares itself to be. Furthermore it’s very easy to tell which browser and version is which when you have properties such as scrollbarShadowColor and MozBorderRadius which are easily accessible to JavaScript. So when a page loads in IE I’m able to detect it’s rendering mode in say IE6 and have the site retract the XML declaration to trigger standards mode when JavaScript refreshes the page. Plus would you really take the time to validate every single page every single time you changed something? Hacks? Using JavaScript is a hack? I think people who use jQuery might disagree with you. πŸ˜€

  36. TK says:

    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?

  37. Tony Ross [MSFT] says:


    > 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="; 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).

  38. 8675309 says:

    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

  39. mark says:

    Any news regarding: HTML5, SVG support, etc?

  40. axe says:

    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.

  41. Mitch 74 says:

    @Gérard: wholly, I agree with you. The thing about X-UA-compatible is that it’s a ‘pure’ override of the DOCTYPE switching process (apart from the Standards/Almost Standard switch, which is really about reflecting a quirk in the standards anyway: after all, what are (X)HTML Transitional modes for?).

    You can, actually, force Quirks mode with ‘IE=5’ as a parameter, which is the setting that should be used on pages intended to render in Quirks mode (those that aren’t, should have a DOCTYPE and be done with it). Although it may seem counter intuitive, it is rather logical, and should actually be commended: DOCTYPE switching is itself a compatibility hack, and it shouldn’t be made into a rule to be followed by other hacks (X-UA-Compatible is nothing other than a more elaborate compatibility hack).

    About Strict: indeed, it’s gone – maybe because it caused confusion? After all, IE 8 may default to IE 8’s engine on Strict DOCTYPEs, but if it has an EmulateIE7 header, then it’ll render in IE7’s mode – which is rather close to what other browsers call Almost Standard, used with Transitional DOCTYPEs. Thus, a Strict page wouldn’t render strictly in that most publicized case! Confusing? Yup. Might as well call it Standards mode, IE7’s mode as Compatibility mode, and be done with it. It sure would have been better had it been made explicit at one time.

    About the trigger system: it sure is complex. And, right, Iki’s chart is far,far more clear. It doesn’t include the Developer tools overrides, though.

    About conditional comments: they have no effect on the page’s rendering _mode_, or at least, none I’ve found. Their working has been explained in an earlier post (a link would have been appreciated, though), and basically, a conditional comment saying ‘if IE lt 8’ would have no effect on IE 8 – except if running in EmulateIE7 mode, as they are intended.

    Tools/documents from MS improving standards support: indeed. Still, I’ve noticed a slight improvement in MSDN documentation. Still not enough, sure, but getting better.

    Websites that want to render in as many browsers as possible will not, usually, aim for pixel perfect rendering. Unfortunately, Standards mode may actually crash older browsers or hide elements if using "old" programming methods. Programming to standards is easier when separating content, interaction and visuals (separate HTML, script and CSS), but is not dependent upon it: nothing prevents you from writing an external CSS stylesheet and script file for an HTML tag soup page… And yet, that page will render more consistently in more browsers (since they could merely not download these external files) than a Standards-abiding page with loads of included style and scripts (either tagged or inline), which may cause it to crash.

    As for the default mode, eventhough the diagram dilutes it a LOT, if you write a page with a ‘DOCTYPE html’ opening it (or any Strict DOCTYPE, actually), and nothing more (no X-UA-Compatible meta tag, no header), it will, indeed, render in the most compliant mode – provided third-parties (your host, Microsoft’s compatibility list) don’t change that. But it hardly is ‘default’ then.

  42. Ingo Chao says:

    We blogged about why and how we migrated XING’s rendering in IE8 from Compatibility View to Standards View.

  43. @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).

  44. Paul McKeown says:

    >>>With XHTML one does not need the validator save for minor issues such as duplicate id’s which isn’t an issue with good coding practices such as using very specific/unique names.>>>

    Nonsense on stilts.  Pages should always validate, there is no good reason for invalid x/html.  You may find that duplicate id’s are a minor issue, but that’s meaningless chunter, the result of using duplicate html ids is undefined, which is logical, as the point of an id is to provide a unique hook for specific processing.  A browser designer may choose to allow his browser to do whatever he wants on encountering duplicate ids.  Use a class rather than an id under such circumstances.  Note that html5 may possibly define what action browser should take on encountering this error, I haven’t checked, as I try not to gigo my code, and I don’t design browsers.

    >>>good coding practices such as using very specific/unique names>>>

    I note that the code on your website is replete with this particular coding error.

    >>>Plus would you really take the time to validate every single page every single time you changed something?>>>

    Yes, I do this professionally.  It simply one very small step in the quality chain, costs next to no time and saves loads of time that would be otherwise be lost tracking back later to the source of rendering errors.

    I would also recommend a good templating system, which will automatically and correctly generate much of the framework html for your pages, reducing the scope for human error.

    >>>Hacks? Using JavaScript is a hack?>>>

    Ah, the old strawman defence.  Go on, have a tilt, but it’s not what I wrote, as you should know if you read it.  What I did say is that javascript browser sniffing is a bad idea, not


    If you read the specification for the UA string, you will find that it is is free text, and intended for reports, etc., certainly not to be used for critical processing.  I find your whole approach bizarre – you hanker after the dependability of xhtml, yet you are happy to apply hack upon hack to achieve your goals.  Fact is depend on the UA string at your peril, your code will not work in lots of browsers.  Simple fact.  Proxies, anonymisers, browser add ons, new browser versions, users themselves even, can all do strange things to the UA string.

    If you need to identify IE browser versions to provide specific css or jscript to correct for its flaws, then the approved method is to use conditional comments, either in html or in jscript.  To guarantee javascript/ecmascript/jscript robustness, you should use feature detection and a logical design to ensure correct default behaviour when the feature is not available.

    Browser sniffing should really only be used to ensure that your pages remain reasonably accessible to the occasional visitor using an ancient or incapable browser, where the UA string is well known (if the string sent is different from what the browser’s manufacturer installed, then there is nothing you can do, and in fact you have done everything possible to accommodate and provide accessibility).  Such ancient browsers might include, for instance, Safari before 2.0.4, which maddeningly included the preventDefault method (so feature detection would not work to exclude it), but which didn’t actually prevent the default action when invoked.

    Well, actually, browser sniffing may be useful to consider also if you wish to employ advanced caching and versioning methods on the server, but you will need to carry out very extensive testing before releasing to production.  Not for amateurs.

    >>>Also I know application/xml mode still handles the code as HTML to some effect though>>>

    Actually it handles the page pretty much completely as html, as you use xslt, which is basically instructions on how to convert xml to html.  The instruction is simple in this hack, take all of this xhtml and process it further as html.  It’s nothing new, the trick has been known since 2004 or thereabouts, but it is essentially pointless.  Believing that this is xhtml is delusional.

    >>>it would be nice if ‘render as text/html’ option was made available when an XML parse error was detected>>>

    An interesting idea, which has been suggested before.  What would really happen, is that if an xhtml document failed xml parsing, and if the appropriate browser flag was set, that the document would be sent to the html processing instead.

  45. @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

  46. @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.

  47. Rob Parsons says:

    The issue is how OTHER browsers determine the rendering mode. Like et al the ‘standards’ are subjective.

    Validators are’nt validated Tinto!

  48. whats up with the comments says:

    comments that were originally published (that did not violate the TOS) have been removed.

  49. ieblog says:

    @whatsup: The IEBlog Comment Policy is here:

    Comments which do not abide by this policy are removed.

  50. Paul McKeown says:

    @John A. Bilicki III

    You use the term "browser sniffing".  This has a rather specific meaning, attempting to determine the type and version of a user’s browser from the various ways a browser varies from or complies with written standards or from the UA String.  It is a technique which is generally contrasted with those of progressive enhancement, graceful degradation and feature detection.

    That you go to the trouble to compile a list of supported/non-supported DOM features, rather than depending on the UA string is just sweet.

    However you have no guarantees from any browser manufacturer that these DOM idiosyncracies are indeed unique to their particular browser or version, that they will always be present, nor have you the guarantee that no other browser manufacturer will not copy or drop any particular feature that your algorithm depends on.

    "scrollbarShadowColor" supported by some IE versions – but perhaps dropped in some future standards based IE browser – and not supported by any other browser…  oh, but wait, what about those Opera users who may have enabled its use by editing their User Prefs?

    Or "-moz" – what exactly is Mozilla’s policy for when the property is standardised, will the corresponding "-moz" property continue to be supported or not?  Blow me, I don’t know.  Nor could I be bothered to find out.

    In other words, a nightmarish maintenance headache.  That particular groups (you mention jQuery iirc) use some such technique, hardly mitigates this.  jQuery, at least is maintained by a large team, so they can afford to expend effort ensuring that such hacks continue to work as browsers change.  It doesn’t mean that the technique is generally good to use, when other methods can do much of the work more reliably.

    Perhaps you enjoy being the master of such labyrinthine code, well each to their own.

    And to make it more unreliable still, you do the sniffing on the client, when, of course, not everyone has javascript enabled.  Great, if you don’t enable javascript, the site may be unusable, ah, but that doesn’t matter, really.

    Accessibility, who needs it?

    Browser sniffing is a good name for the technique, smells like, but doesn’t mean to say that the identification is correct, nor that your nostrils are not going to end up with something nasty.


    A content div with the id "news" and a sidebar div the same id?  Who knows what tool created that, but it’s wrong in any case.

    As for completely failing invalid pages, most people would see that as a problem with xhtml for the unwashed masses, not as a benefit.

  51. Dazza says:

    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?

  52. Dazza says:

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

  53. ieblog says:

    @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?

  54. Dazza says:

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

  55. Paul McKeown says:


    Actually, just looked up jQuery support for browser sniffing.  It is deprecated as of version 1.3, vid. .  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: , which is a fabulous, if rather difficult article.

  56. Chris says:

    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??

  57. Mitch 74 says:

    About browser sniffing: it is only to be used in the direst of situations, such as a browser not supporting gracious fallback at all.

    In other cases, stuff like very precise object detection (using Jscript compiler directives to probe an IE version’s Jscript level, conditional comments with very specific settings) will more often than not allow a good, durable bug fix. It is how tight you make your object detection that determines how effective your workaround will be.

    For example, conditional comment that do ‘if IE’ are worthless. You should, at the very least, do:

    ‘if lte IE 7’ for IE 5/6/7, then (with some syntax tricks to make the code snippet NOT appear as a comment) ‘if gte IE 8’ to cover W3C, IE8 and later browsers. Other tricks, such as the use of @import for CSS, are a bit more tangent: they are well documented (a recent browser MUST support the syntax to be ‘CSS valid’, but it is still a hack)

  58. Enrique says:

    Internet explorer 8 ISN’T work in Windows server 2003 πŸ™ ,,, i can’t install that =( ..

    only work in Server 2003 SP2, why?? :S ..

Comments are closed.

Skip to main content