IE’s Compatibility Features for Site Developers

Site developers have been clear that they want interoperability and standards compliance (or “Same markup”) for newer technologies as well as backward compatibility for their existing sites. After reading questions and comments on the last few compatibility-related blog posts, I thought now is a good time to recap IE’s compatibility features for site developers.

As IE changes and supports new technologies, developers will still want, in some scenarios, IE’s legacy behavior. There are many different technologies that enable developers to adjust how IE runs their site’s markup.  The main ones include the IE Developer Tool’s Browser Mode and Document Mode, X-UA-Compatible Meta tag and HTTP Header, and Conditional Comments. I’ve also updated the How IE Determines Document Modes diagram for IE9 based on suggestions from the developer community.

Browser Mode and Document Mode

Many blog comments asked about the difference between Browser mode and Document mode. There are good articles on MSDN about the Browser Mode and Document Mode menus in Developer Tools. Here’s a recap on how to use these menus to test your website.

The Browser Mode determines what User-Agent (UA) string IE sends to servers, what Document Mode IE defaults to, and how IE evaluates Conditional Comments (More on these topics below). By default, IE9’s browser mode is IE9, and IE8’s browser mode is IE8. As a developer, you can change this in IE’s Developer Tools with the “Browser Mode:” menu item. The user can change this when visiting a site by clicking on the Compatibility View (CV) button manually.  Most users opt-in to the CV List that Microsoft updates based on work with the community.

Browser Mode



IE9 reports a UA string, version vector, and document mode to match the default browser behavior, which is the most standards-compliant mode in IE9. Use this mode to test how IE9 users experience your site.

IE9 Compatibility View

IE9 reports a UA string, version vector, and document mode, as if it is IE7; however, the UA string also includes the Trident/5.0 token indicating that the browser is really IE9. Use this mode to test how IE9 users experience your site if they click on the Compatibility View button. Note that the Developer Tools in the second IE9 Platform Preview has two Compatibility View options, which is a known issue.


IE9 reports a UA string, version vector, and document mode as if it is IE8. Use this mode to test how IE8 users experience your site.


IE9 reports a UA string, version vector, and document mode as if it is IE7. Use this mode to test how IE7 users experience your site.


The Document Mode dictates what mode IE’s Trident engine will render the markup in such as IE9’s Standards Mode. Changing the Document Mode refreshes the page, but does not resend the UA string or retrieve new markup from the server.

Document Mode


IE9 Standards

This is the latest standards-compliant behavior available in IE9, and is the default mode used by IE9 to render a webpage that have a strict or unknown document type.

IE8 Standards

This behavior matches IE8 when it renders a webpage that has a strict or unknown doctype.

IE7 Standards

This behavior matches IE7 when it renders a webpage that has a strict or unknown doctype.


This behavior matches IE when rendering a document with no doctype or a Quirks doctype. It is similar to the behavior of IE5 and the Quirks mode behavior of IE6, IE7 and IE8.

Changing the Document Mode for your site

As a developer, you determine the document mode that IE will use when rendering your site. By default, it’s the most interoperable and standards-compliant mode, which is IE9’s Standards mode in IE9. You can use the doctype and X-UA-Compatible Meta tag or HTTP Header to change that default as you see fit. You can use the “Document Mode:” menu item in IE’s Developer Tools, to see what mode makes the most sense for your site.

If you want to change the Document Mode for just one specific webpage, the Meta tag is the most convenient way. To change the Document mode for many pages across your site, changing the HTTP header is convenient.

IE9 will support two new X-UA-Compatible values in addition to what IE8 supports:

Meta tag or HTTP header content = “IE=______”



EmulateIE9 tells IE to use the doctype to determine how to render content. Web pages with no doctype or a Quirks doctype are rendered in Quirks mode. All other doctypes are rendered in IE9’s Standards mode.


IE9 tells IE to render in IE9’s Standards mode and ignore doctype.


We’re encouraging site developers to use a standards doctype and no X-UA-Compatible Meta tag or HTTP header when targeting IE9’s Standards mode. This helps us all reach the goal of running the same standards-based markup.

If you have a legacy site that relies on IE7’s interpretation of Standards mode use the X-UA-Compatible Meta tag or HTTP header to target IE7 Standards mode. Here’s an example that combines values so that IE8 renders a webpage in IE7 Standards mode while IE9 renders the webpage in IE9’s Standards mode:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7; IE=EmulateIE9">

You can achieve this result for many pages at once by changing the HTTP header to add this logic to some or all pages on Apache servers or IIS servers.

In order to help deliver on the “same markup” goal, there’s one additional change from IE8 to IE9. All iframes within a top-level page rendering in IE9’s Standards mode will also render in IE9’s Standards mode. The only exception is that iframes that specify Quirks mode will render in Quirks mode.

Detect features, not browsers (or, Avoid Conditional Comments)

We want to run the same standards-based markup as other browsers in IE9’s Standards mode. This is why we’re encouraging developers to use feature and behavior detection and the same stylesheets when targeting IE9 and other browsers’ Standards mode.

We strongly recommend feature and behavior detection rather than Conditional Comments, an IE specific feature that other browser vendors have chosen to not implement. Conditional comments will not work across browsers and are not “same markup.”

There is one case where it is appropriate to use Conditional Comments, which is for backward compatibility with IE6 or IE7 stylesheets. For example, websites such as use Conditional Comments to load specific stylesheets in IE7.

<!--[if IE 7]>
<link rel="stylesheet" href="" type="text/css" />

IE9 will continue to support this as part of our commitment to be backward compatible for existing sites. Here are a few rules that will help you apply Conditional Comments:

  • Conditional Comments are tied to the UA String by default. Using the X-UA-Compatible meta tag or HTTP header enables a page to specify a specific version for compatibility. If an X-UA-Compatible declaration exceeds the version of IE in use (8 in IE8, 9 in IE9) or is less than 7, then the value from the UA String will continue to be used instead of the version declared in X-UA-Compatible value.
  • The IE version number sent in the UA String is used to evaluate Conditional Comments. This is called the Version Vector. For example, an IE7 UA String will have a Version Vector of 7 and the Conditional Comment <!--[if IE 7]> will evaluate to true. IE9 will only send one of two UA Strings; the IE9 string or the Compat View string.

    UA String

    Conditional Comments evaluate against this Version Vector



    Compat View


To summarize this section, it’s ok to use Conditional Comments to conditionally load CSS that targets IE6 or IE7. Use feature and behavior detection for everything else.

Updated diagram on How IE9 Determines Document Mode

To help illustrate how all of these features work together, we’ve updated the Determining Document Mode diagram for IE9 (in SVG or PNG) with the new X-UA-Compatible values mentioned above. We’ve also updated the diagram based on your suggestions. Thanks!

Marc Silbey

Program Manager

Comments (37)

  1. infinte says:

    It's a great work. (9) will be a reborn.

    In my advice, you should remove COM and OCX in 9-mode. It's needless in modern web sites. please, please!

  2. Matt says:

    I think you should stop using the term "same markup". Browser makers have been able to describe this idea via the term "standards compliance" for a long time and there's no need for another term.

    It makes me think you're up to something. It's kind of like if you were to ask your partner "Do you believe in monogamy?" and they responded with "I believe in exclusive sexual contact."

    So stop it, you're creeping us out.

  3. The Real Matt says:

    Your example is a good one and shows why "same markup" is exactly the right thing to describe as the goal.

    They're not over-promising or misleading, they're being precise. Anything that claims "standards compliance" is basically a lie, because there are so many different standards, and many of them contradict one another. "Same markup" on the other hand, is a proper aspiration: web developers can write the same content and have it run the same way in different browsers.

  4. timeless says:

    Determining Document Mode diagram for IE9

    links to:


    the SVG and PNG links work…

  5. Chris says:

    Of course conditional comments work across all browsers: in non-IE browsers they are just HTML comments and so correctly ignored – however I do agree they should only be used to load legacy stylesheets. Scripts should use feature detection to allow for progressive enhancement/graceful degradation. And by the way posting comments seems to be broken in Firefox…

  6. Steffen Weber says:

    When a website is on the compatibility list maintained by Microsoft and sends "X-UA-Compatible: IE=edge", then IE8 renders the website using "IE8 Compat View" and not "IE8 Standards". There seems to be no way to override this stupid compatibility list and it takes 2 months to get removed from this list (we have been added without being asked). 🙁

  7. Rob says:

    @The Real Matt – If you are aware of other standards than what the W3C/Whatwg publishes, I'd like to know what they are.

  8. Arnold Traore says:

    IE has always been by first love in term of <a href="

    ">developing</a> features are concerned. I would like to know more about the other standards as well related to the IE.

  9. The Real Matt says:

    Rob: Uh, you know that the IETF publishes Internet Standards, right? As well as ISO, ANSI, ECMA, MPEG, JPEG, and dozens of other organizations? Furthermore, you understand that each of these bodies has multiple versions of most standards, some of which obsolete earlier versions, generally without regard to what content may expect the behavior specified in the earlier version? Most of the "standards compliance" we're talking about today relates to "Standards" that aren't– like HTML5, which is still under active editing.

  10. Jeffrey Gilbert says:

    dudes, i appreciate the effort, but i'm just going to continue building my personal sites to starts and specs supported since firefox 2 and if you guys can't push out products to end users that support that bare minimum of functionality, that's not my problem anymore. i'm not testing for your crappy browsers anymore. think it's time to bring back that age old trend of "best viewed in xyz browser" tag that was so tackily adorned to every geocities site back in the 90s

  11. JM says:

    I think four modes are too many for one browser. Quirks mode and IE7 mode are OK, but IE8 mode is redundant.

  12. Meni says:

    Agree whole heartily with infinite and Matt (#1 and #2)

    Also MS should take the plunge and do what Mozilla did and include only web standards, no compatibility mode! Back then they could have, for example, very easily implemented the "all[]" javascript attribute, which would have made sense to support more pages, but they didn't, and thank XXXXX that they didn't.

  13. Dan Dean says:

    How is it that every other browser maker can push updates more often, and leave broken implementations (in your case, everything in IE's compatibility modes) to fade into memory, while you take a huge amount of time between releases AND continue to support broken implementations?

    Until the IE team decides to stop doing that it will continue to release an "innovative" product which is at least 2 years behind the curve.

  14. Matt says:

    Dan: Ask yourself "How is it that Microsoft still has 200% of the browser share of all of their competitors combined?" and you will find that answers your other question.

    Consumers and businesses want reliable, predictable behavior from their browsers. Getting on a constant and unpredictable upgrade treadmill isn't appealing as it has an unjustifiably low ROI.

  15. ieblog says:

    @timeless – thanks, we fixed the link.

  16. badger says:

    @Matt  There are a number of cases where, unfortunately, the standards get it "wrong," aren't specific enough to exactly determine how a browser should act, or are writing for audiences much larger than just web developers and browser vendors (so things aren't tailored to be the best specifically for the web). It is for these reasons that the term "same markup" is much more appreciated. As long as the browser makers get it right and in agreement so that same markup works across the board, then it's good for me.

    There are a lot of examples of this in standards. I'll remind of you one highly publicized example: HTML5 Video. The spec does not (currently) identify which codecs to support. So while multiple browsers might support the standard, that doesn't guarantee same markup across browsers if they support different codecs. Using Opera long enough will dreadfully point this out to you as many sites don't work despite Opera being tremendously standards compliant.

  17. Garrett says:

    I suggest Microsoft curtail the list of supported compatibility modes in IE9. Supporting old compatibility modes extends the duration of legacy support that web developers must deal with. When IE 10 is out, there will not be many IE7 users, but there will still be IE9 and if IE9 has an IE7 view, then anybody writing code for IE10 has to write code for IE9, IE8, IE7.

    Pages must be prepared for the scenario of the user clicking it.  Scripts can't rely on things like native JSON or querySelectorAll, not with that button.

    The complexity with cross-browser scripting is not so bad these days, but the compatibility view button extends the duration of legacy support. This, in turn, encourages more naive approaches such as browser detection, which most know better, yet some (google and yahoo) seem to be oblivious to:…/reversing-code-bloat-with-javascript.html

    The viewpoint is quite naive and the advice that follows is truly harmful. The reason I am posting it is to show an example of cross-browser scripting mistake. Compatibility modes add additional complexity and that encourages posters such as Mike Samuel to use techniques such as browser detection — after all, you can't download "all that code" for all those browsers……/yahoo-unsupported.png

    It has also been noted that the IE installer provides an option to allow compatibility mode to be updated or not.

    "Do you want to use Compatibility View updates?"

     [ ] Yes, I want updates

     [ ] No, I don't want updates


    "We’re encouraging site developers to use a standards doctype and no X-UA-Compatible Meta tag or HTTP header when targeting IE9’s Standards mode. This helps us all reach the goal of running the same standards-based markup."

    MSDN shows the opposite on literally thousands of highly-trafficked pages and has done so for years. It does this with invalid HTML and demos designed to work only in IE (sometimes even failing at that (e.g. "filters")).

    Conditional Comments, updated as recently for IE8:…/ms537512(VS.85).aspx

    — with <SCRIPT LANGUAGE="Javascript">…/aa770069%28v=VS.85%29.aspx

    States that a selector is specified in "HTML"; uses <style> (no type attribute).


    On to my next topic: Host Objects

    Host objects are unweildy in IE. MSIE implements "dhtml collections" as unwieldy error-throwing objects poses an obstacle at a fundamental level. That problem needs to be addressed by Microsoft. Instead, MSIE should implement its DOM host objects as native ECMAScript objects.

    Errors in IE: document.body.childNodes );

    If IE were to implement host objects as native ECMAScript objects (or indistinguishably so), then the algorithm defined by the ECMAScript specification would be used to result in an Array.

    Host objects also throw errors on [[Get]] access and type conversion. Accessing element.filters.alpha, or document.styleSheets[99999], for example, will sometimes result in errors.

    It would be good to see IE implement every host objects as a native object.

    DHTML Collections:…/ms533048%28VS.85%29.aspx

    That page also contains the nonstandard Comment "Elements", which is also included in things like element.children.

    Good intentions in your blog post but compatibility view will extend the duration necessary for future legacy support (IE7 in five years). The complexities with compatibility mode will further scare developers into using things like browser detection.

  18. Klimax says:

    To get rid of compatibility you need first to fix all the bad code in the world and hide any articles which suggest broken code (which could be good at the time).

    Specifically this applies for intranet apps where somebody will have to pay such rewrite otherwise you'd ensure IE6-like hell which already is bad…

  19. Snark says:

    I suggest Microsoft curtail the list of supported compatibility modes in IE9. This will help ensure that users don't upgrade to the new browser and then we web developers don't have to learn to take advantage of all of the shiny new html5 and css3 features in IE9. Also it will help teach users patience because they can use an older slower browser that isn't hardware-accelerated.

  20. Wurst says:


    Firefox has basic support for document.all in quirks mode:

  21. Rimas says:

    @ieblog: I don't quite get why you would need conditional comments in IE9 standards mode. If you really intend to be standards (or single markup) compliant, then perhaps you should only see conditional comments as such in legacy modes, and see them as nothing but plain comments in standards mode? Targeting IE9 or higher by using CC's like <!–[if IE 9]> never made any sense in the past, so there isn't legacy to support in it, so why do you want to support it?

  22. EricLaw [MSFT] says:

    @Rimas: Conditional comments are an IE feature that can be used beyond just "if IE". You can use them as a mechanism to expose other conditional behavior based on any registered version vector. See…/ms537512(VS.85).aspx for more information.

  23. Marcsil [MSFT] says:

    @Steffen Weber: The X-UA-Compatible value of “IE=edge” can be used to override the Compatibility View list. This tells IE to render the site in the latest Standards mode. If you’re using the meta tag, make sure that it’s in the webpage's header before all other elements, except for the title element. If it still isn’t working, we’d love to find out why and help you get it to work.

    I’m sorry to hear that you weren’t asked about being added to IE8’s Compatibility View list. We always attempt to contact each site before adding it to the list. I want to make sure that we have the right contacts for your website and that we remove it in an upcoming Compatibility View list update. If you wouldn’t mind, please email us ( and include a link to the website that “IE=edge” isn’t working for.

  24. Mitch 74 says:

    I'm really starting to hate the comments on this blog: my comment AGAIN failed submission!

    I was saying the new graph is much more clear than before, but I wanted to ask a question:

    what happens to an application/xhtml+xml document if it contains a X-UA-Compatible mode for an IE version that didn't support that mode? Or, if a website is marked in the MS compatibility database as Compatibility, but calls for that MIME-type?

  25. Marcsil [MSFT] says:

    @Mitch 74: Thanks. A document that has an application/xhtml+xml MIME type will render in IE9's Standards mode regardless of whether the site is on the Compat View list or uses an X-UA-Compatible value. The same document will trigger a file download on IE8 and earlier versions of IE because application/xhtml+xml is not a recognized MIME type in these versions.

  26. Steffen Weber says:

    @Marcsil: Thank you for the reply. I'm already in contact with and have found out that the X-UA-Compatible header lets you override the "Document Mode" but not the "Browser Mode". We'll be removed from this list in mid August which is still 2 months away… but better than nothing. IMO all these compatibility switches in IE are a total mess. Seeing even more of this stuff in IE9 frightens me.

  27. @Marc Silbey [MSFT]

    1- "(…) for IE9 based on suggestions from the developer community."

    "We’ve also updated the diagram based on your suggestions."

    Because of the new blog version, link fragment #9971775 is unretrievable, unreachable, inaccessible.

    2- "[meta-tag X-UA-Compatible value] IE9 tells IE to render in IE9’s Standards mode and ignore doctype. (…) We’re encouraging site developers to use a standards doctype and no X-UA-Compatible Meta tag or HTTP header when targeting IE9’s Standards mode."

    What this IE9 meta-tag X-UA-Compatible value does (functionality) to a webpage contradicts completely and absolutely what you are explicitly encouraging. This meta-tag X-UA-Compatible functionality should always have been compatible with the doctype declaration triggering system. An IE9 meta-tag X-UA-Compatible value in a doctypeless webpage will be rendered in backward-compatible "quirks" rendering mode in all non-IE browsers when it will be rendered in standards compliant rendering mode in IE9: a blatant anti-web-interoperability result and an impredictible one.

    3- "we’ve updated the Determining Document Mode diagram for IE9 (in SVG or PNG)"

    Please clarify everywhere appropriate (diagram, article, blog post, MSDN, books, websites, etc) the difference between

    <meta http-equiv="X-UA-Compatible" content="IE=9">


    <meta http-equiv="X-UA-Compatible" content="IE=IE9">


    Same thing for

    <meta http-equiv="X-UA-Compatible" content="IE=8">


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

    4- In my opinion, this compatibility view button should be removed for IE9.

    regards, Gérard Talbot

  28. Saad says:

    I hope IE 9 save pages fast like Google Chrome.

  29. Krynolino says:

    Just great! Now you have to prepare code for four versions of IE! Fantastic! Thank you Microsoft.

    There will be always work for programmers. Can't wait IE16! Conditional comments and meta headers for 10 browsers! Fantastico 😉

  30. Rimas says:

    @EricLaw [MSFT]: I know you can target specific version of IE with conditional comment. The point is, you're advocating single markup here. Conditional comments just don't fit into that picture, and assuming IE9 (in IE9 mode) will be as good as other browsers in terms of compatibility, I fail to see how leaving this feature is desired.

    Again: I don't suggest to drop support for it whatsoever. My suggestion is to drop its support in IE9 Standards and later modes. CC's are great for fixing layout problems in IE6 and IE7, but if your intentions about compatibility are serious, you just don't need CC's anymore.

  31. Mitch 74 says:

    @Rimas: what exactly is the problem with conditional comments? For ONCE, we have a IE feature that don't piss off other browsers or create invalid markup! And it is useful: IE 9 will be with us, _LAYOUT_BUGS_AND_ALL_, until 2020 – IE 6 didn't cause much trouble (with table-based layouts) when it came out, it's only when web programmers started pushing it that it cracked up.

    If only the syntax for 'IE above a certain version and all other non-IE browsers' wasn't so f**ked-up…

    Other browsers update faster; they don't depend on the OS editor for support, and us web authors don't need to support, say, Firefox 1.0 or Safari 2.0 any more; the most serious still have to support IE 5.0 (until next month, end of extended support for Windows 2000), 6 (XP, until 2014), 7 (Vista, until 2017) on top of 8 (until 2020) and 9 (tentatively, 2022).

    Just imagine that, for whatever reason, an SVG parameter ends up supported backwards in IE 9; after RTW, you can _KISS_BUG_FIXES_GOODBYE_ in IE (the IE7 100% CPU regression  on variable sized elements out of viewport in overflow:scroll elements has been retained in IE 8 and 9 Compat mode, eventhough it can _CRASH_THE_BROWSER_ – it's not a bug, it's a feature), so you'd have to implement another hack in all your SVG documents until 2020 – if you didn't have CC's.

  32. wafsd says:

    Backwards compatibility is vital to maintain legacy apps until they can be updated. These are bigger issues than whether they look nice. This often has to do with support contracts and guarantees that require use of IE6 or IE7. Use IE8 (or *any* non-IE broswer) and your support contract is void. When the application in question is customized SAP, well kids, you stick with the older browser since you can't run your business w/o your ERP system.

    Frankly, IE giving enterprises ways to maintain old stuff until it can be updated or retired is one reason why other browsers don't make much headway in the enterprise space. Simple ways to keep marginal apps and web sites running while newer stuff can take advantage of the newer browser features is a way to ease transition to a newer browser and to avoid budget shocks.

  33. EricLaw [MSFT] says:

    @Rimas: Sorry, but you're missing my point. Conditional comments can be used to target things *OTHER* than then Internet Explorer version. You can read the MSDN article to learn more.

  34. @Mitch74

    > Other browsers update faster; they don't depend on the OS editor for support

    True. Non-IE users are overall, generally always much faster in upgrading their browser.

    On this blog, there is always 3 types of problems discussed involving the 3 entities which creates the web.

    Users with their browsers: People not (or slow at) upgrading their browser and using IE6 or IE7.

    Browser manufacturers: Microsoft not complying with web standards and not fixing bugs, or being last or very slow to meet and honor web standards.

    Web authors: And then there is web authors not updating their webpage code (valid markup code, valid CSS code, document properly structured, etc) and not upgrading their coding techniques. That's probably the most difficult challenge on the web right now.

    And this IE8+IE9 complex backward compatibility functionality (button, settings, checkbox, http headers, meta-tag, managed lists, etc) kind of glue/cement everything firmly together. Thanks to it, there is less incentive to upgrade/update.

    > still have to support IE 5.0 (until next month, end of extended support for Windows 2000), 6 (XP, until 2014), 7 (Vista, until 2017) on top of 8 (until 2020) and 9 (tentatively, 2022).

    This is certainly very awful to read: definitely a very miserable system. IE7 is certainly not a browser to have around, to use for the next 7 years. I can't believe that after 2014, we will have people using IE7.

    > the IE7 100% CPU regression  on variable sized elements out of viewport in overflow:scroll elements has been retained in IE 8 and 9 Compat mode, eventhough it can _CRASH_THE_BROWSER_ – it's not a bug, it's a feature

    That kind of bug hangs the application, with an underlying infinite  reflow loop: it makes the application unresponsive and more prone to crash. If they have not fixed such bugs, then they should for IE8 compat mode and maybe they should contact the websites to warn them about such bugs.


    > This often has to do with support contracts and guarantees that require use of IE6 or IE7. Use IE8 (or *any* non-IE broswer) and your support contract is void.

    Who signed such contracts? Who agreed to such contracts? Who bound/handcuffed/tied up a company (and its future) to such constraints?

    > When the application in question is customized SAP, well kids, you stick with the older browser since you can't run your business w/o your ERP system.

    The top 20 IT mistakes to avoid

    11. Developing Web apps for IE only

    NOVEMBER 19, 2004…/top-20-it-mistakes-avoid-314

    regards, Gérard

  35. Mitch 74 says:

    @Gérard (on CC's): and this is exactly why, considering how crummy any IE version ends up after a while, that we need CC's: it is the only non-hackish way to keep an IE version afloat for a while without having to worry about forward compatibility – who can predict how the star hack, or the leading underscore hack, would react to future versions of CSS?

    Of course, had IE not been the most used browser in the world due to monopoly abuse, I could care less about CC's – IE's share would be so low, I could apply Okham's razor and not care about it. Thanks to Vista being the 'fastest selling MS OS ever' in 2006 (since it was a forced install on all sold PCs), us web devs now have to support a few million users that refused IE 8's install – and the great non-conformant positioning of absolutely positioned blocks, the splendid impossible to reduce margin of LI-displayed elements in an UL-displayed container, and the greatest of all, the 100% CPU/crash bug I already described!

    Please note that the last two bugs are regressions over IE 6, now kept forever in IE's Compat mode. Yay. As if reproducing a crash was a needed feature.

    We will also, thanks to IE 9's great timing, have to support IE 8 ANYWAY until 2014 AT LEAST, for all those XP users (or downgraded Vista users) left in the lurch; that means, supporting hover bugs when applying a filter (to compensate for the lack of CSS 3 properties), ensure that text files are loaded as text even if they contain stuff that looks like HTML, or simply correct the number of nodes because IE can't count white spaces (seems that IE 9 also got a variant of this bug, luckily it might be solved before RTW).

    Even though IE 9 is shaping up to be very good, it'll probably be slightly outdated by the time it reaches RTW; but, IE's versioning is such that, even if IE 9 was to become the Ultimate Browser ™, IE 8 and lower will still be a pain in the a**e to everybody for quite a while.

    I'd rather keep the CC's to, at least, not have to look for hacks on top of which I can make my future hacks work. The very value of CC's is that, due to their existence, NOBODY will ever consider tampering with comments – There Be Dragons – and I'd rather forget about server-side UA detection and CSS strings like _hover:value or voice-family: ""}"";voice-family:inherit; . CC's allow me to hack a page for IE and still have valid code that will be read correctly by all browsers to come in the next 10 to 20 years. Which is rather cool.

  36. Rimas says:

    @EricLaw [MSFT]: Thanks for pointing out the fact that I can use other version vectors than just IE's in Conditional Comments. However, I still think it isn't used often for anything but targeting specific IE versions, and doesn't at all go along with the Same Markup paradigm IE devs are now advocating. I still think it could be painlessly dropped from future rendering modes, including IE9 standards.

  37. says:


Skip to main content