Compatibility View and "Smart Defaults"


I’ve mentioned in several previous posts how Internet Explorer 8 displays pages in its most standards compliant mode by default – a configuration that emphasizes interoperability. This creates some challenges with regards to compatibility with existing web content.

Some of today’s web pages expect the older, less interoperable behavior from IE and, as a result, don’t necessarily work as expected in IE8’s standards-by-default mode. To address this, we built features like Compatibility View and the ‘EmulateIE7’ X-UA-Compatible tag – features that users and web developers can enable to make the browser more compatible with existing content. This post is about some situations where IE uses smart defaults to provide users with a more compatible out-of-box experience.

Many sites found on corporate intranets (read: the local network, like http://myPortalSite) are Internet Explorer 7 capable today and expect “IE” to act like IE7. In order to preserve compatibility with these line-of-business websites and applications, IE8 defaults to Compatibility View when displaying content in the ‘local intranet’ zone. An exception to this is ‘Localhost’ and the loopback address (e.g. 127.0.0.1 + IPv6 equivalent). These addresses display in IE8 Standards Mode by default in order to meet the needs of web developers and designers who often test pages meant for Internet consumption (where IE8 Standards is the default) on local web servers.

Users can override the ‘local intranet’ setting by un-checking ‘Display intranet sites in Compatibility View’ at Tools -> Compatibility View Settings.

Compatibility View Settings dialog.  At the bottom is an option to automatically display intranet sites in Compatibility view.

IT Admins can configure this setting via Group Policy. IT Admins can also configure and maintain a list of sites, both intranet and extranet, that are best viewed in Compatibility View. Using that policy in conjunction with the ‘local intranet’ policy configured to “off”, e.g. IE8 Standards on the intranet, enables organizations to gradually transition infrastructure pieces from IE7 Standards to IE8 Standards.

Another place where IE uses smart defaults is WebOC layout modes. There are many Windows applications both past and present that use the WebBrowser control, aka Trident. CorelDraw Graphics Suite, Encarta, Microsoft Office, and Nero are just a few examples. As you might expect, updating software that the user has installed on their machine is complex (e.g. developer has to write an updating system, user has to opt-in, user has to get and install the update, etc…). This can be particularly hard for “boxed” software, which often times is even more costly to update than a “live” web application due to the software distribution method – CDs / DVDs on store shelves vs web download. Like web applications, these Windows applications may assume a particular behavior set from Internet Explorer. In order to maintain compatibility, applications using the IE8 WebOC display pages in Compatibility View by default. Applications can enable IE8 Standards Mode by setting the following registry value:

[(HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE)\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
“MyApplication.exe” = dword 8000 (Hex: 0x1F40)

Finally, there are cases around “hard asserts” that cause IE to switch into Compatibility View. For those not familiar with the concept, Wikipedia does a good job covering the basics – 

An assertion may be used to verify that an assumption made by the programmer during the implementation of the program remains valid when the program is executed.

A major advantage of this technique is that when an error does occur it is detected immediately and directly, rather than later through its often obscure side-effects. Since an assertion failure usually reports the code location, one can often pin-point the error without further debugging.

When we built the brand-new layout engine included in IE8, we used a standard practice of instrumenting common code paths with assertion logic. This instrumentation was invaluable during IE8 development as it served to highlight areas of faulty logic or invalid assumptions made during the implementation of the new layout engine. As an example, the original implementation of some sizing algorithms assumed ‘consumed height’, an internal construct tracking the actual height taken up by an object, could not be negative. This assumption turned out to be false as one can reach the condition through certain top margin values. An assertion that bounded consumed height’s acceptable values allowed us to identify and correct the error.

For the most part, we’ve removed assertions from our retail code. That said, there are particular code paths within the new layout engine where, should an error occur, the layout process can’t gracefully recover and we’ve kept assertions around these paths. In the IE8 Beta builds, encountering one of these layout “hard asserts” caused IE to display a blank page – the thought process being that it was better to show the user nothing at all than allow interaction with a corrupt or otherwise obviously incorrectly displayed page. We refined this experience further in the released version of IE8 by recovering layout “hard asserts” using Compatibility View. In other words, we believe that showing a page the way IE7 would have offers a better user experience than showing no content at all.

viks.org site displaying content in Compatibilty View Viks.org showing a blank page

A new InetCPL setting at Tools -> Internet Options -> Advanced -> Browsing enables / disables auto-recovery.

Internet Options, Advanced Options Panel, includes an option to automatically recover from layout errors

On error, the entire domain recovers into Compatibility View, not just the page or sub-section of the site. This mirrors the current experience when users press the Compatibility View button and prevents a case where the user has repetitious “blank pages” while browsing a site (imagine a case where an ad banner present on all of a site’s pages triggers the assertion). A new balloon tip message indicates that the page has been switched to Compatibility View and why.

Balloon tip message that the page has been automatically recovered.

 

Compatibility View triggered by automatic recovery persists only for the life of the IE session – a behavior that mirrors the current experience when toggling Compatibility View while in InPrivate mode but contrasts with toggling Compatibility View in a normal browsing session (where Compatibility View information for a domain persists across browser restarts). In other words, each subsequent visit to the site (in a new session) will result in a return to IE8 Standards behavior.

When a domain has been auto-recovered, the Compatibility View button shows as pressed (as opposed to hidden or not pressed). Pressing the Compatibility View button on a recovered domain forces a page reload into IE8 mode. The catch here is that toggling in and out of Compatibility View on content that triggers an assertion can cause a recovery loop: site content triggers auto-recovery to Compatibility View, user presses Compatibility View button which takes the page back to IE8 Standards Mode, site content when put through the IE8 layout engine again triggers auto-recovery to Compatibility View…

Auto-recovered domains are shown in the user’s Compatibility View list (Tools -> Compatibility View Settings) in parenthesis.

Auto-recovered domains in the list of websites to view in Compat mode

 

The parenthesis denotes non-permanence. These “temporary” domains can be removed, though doing an ‘add’ operation for an auto-recovered domain in the list replaces the auto-recovered domain with a “persistent” entry (e.g. one without parenthesis).  

The presence of an IE8 X-UA-Compatible tag / HTTP header (e.g. ‘IE=8’ or ‘IE=EmulateIE8’ + a Standards DOCTYPE) forces a page to stay in IE8 mode regardless of the auto-recovery setting value on the client (users will see a blank page in the event of a layout ‘hard assert’). Developers can debug blank page issues by forcing the page into an IE8 document mode via the Developer Toolbar, which will also prevent auto-recovery.

We worked hard to fix known causes of unrecoverable errors in our layout engine before we shipped. For issues that do crop up “in the wild”, IE generates error reporting via Windows Error Reporting (WER). That way, we can get a call stack of the failure and, ultimately, repro, triage, and fix assertions just as we do reported crashes and hangs.

Recap

IE8’s standards-by-default configuration supports developers and designers as they create the next wave of web pages, applications, and experiences. At the same time, we recognize the near term consequence of this decision, namely challenges around compatibility with existing content designed to work with older versions of IE. The behaviors described here enable both interoperability and compatibility, benefitting both developers and end-users.

We’re interested to hear your compatibility feedback. Please drop us a line in the comments section to let us know your experience with IE8 and the content and apps you visit / use.

Scott Dickens
Program Manager

Comments (27)

  1. Geld lenen says:

    Very useful. Personally I find the compatibility view not very handy because it didn’t work a few times. I didn’t know about the options given here though.

  2. What I don’t like about the campatibility view is the time it takes to reload your site in the browser.

  3. Ver Noss says:

    Microsoft promised that pages would go into standards mode by default. Obviously, you have changed your mind. This is another example of Microsoft breaking its promise to support standards.

  4. qualitydirectory says:

    Helpful tips! As a developer I know these behaviors you described here will benefit me a lot. But I’m worried about ordinary end-users who have no knowledge about how to make these tweaks. Many of them don’t read blogs to learn how different IE8 is from IE7 and how it works.

  5. Brian LePore says:

    @Noss,

    Microsoft’s statement was that it would load Web sites in standards mode by default. This is the case. It loads intranet sites in IE7 mode by default. These are what Microsoft actually said. It may not be what many developers heard, but that is the truth.

    One question I have for Microsoft is: When did the "Smart Defaults" setting for IE8 come in to play? I swear that this did not used to be the case as I remember sites I visited on localhost were coming out in compatibility view and then I’d need to turn to IE8, but that doesn’t seem to be the case anymore (and is in line with the article). Was this not the case at launch and requires a Windows Update for this behavior?

  6. evan says:

    The only thing that sucks with this is that the IE7 compatibility mode isn’t exactly IE7.

    Thus 2 new problems emerge.

    1.) Developers now have to test on:

    IE6, Native IE7, Faked IE7, & IE8

    (4 IE browsers vs. the 2 they previously tested on (e.g. IE6, IE7)

    2.) Even though the idea is to move towards standards (much approved) allowing access to broken legacy IE7 rendering "Holds back the Web" indefinitely.  I sincerely hope that IE9 has NO SUCH compatibility option.  Or worse yet has a 3-mode option… a.) IE7, b.) IE8 and c.) IE9

    ev

  7. ShadowChaser says:

    Evan, I think the IE7 compatibility mode does the opposite of what you say – it actually "moves the web forward".

    Take a look at what happened with IE7’s release – many large corporations (including mine, shamefully) still run IE6 for all users.

    The reason is they have a large number of intranet applications they don’t want to spend money fixing. IE8’s defaults allow corporate machines to be upgraded, and allow internet sites to follow the latest standards.

    Your own web stats prove this – something like 10-15% of users still run IE6, and most are in the corporate world.

    I’d actually hope that IE9 includes an IE6 mode – we need to get these people upgraded and off of IE6 so we can start using modern standards.

  8. Mike Morley says:

    Why would you assume that "sites found on corporate intranets" expect “IE” to act like IE7?

  9. EricLaw says:

    @Brian LePore: This change was made for either Beta-2 or RC1; it definitely was done before RTM.

    @Mike: Because we talked to hundreds of companies and got thousands of reports from users.  Of course, as Scott noted, this is entirely under control of the user or GP Admin, so organizations that want Standards mode on their Intranet by default can easily configure it that way.

    @ShadowChaser: Indeed, you’re right.  What many fail to realize is that if IE8 doesn’t offer great compatibility, by default, with Intranet sites, then corporations will not roll it out, and then the Internet at large will not see the benefits of improved standards-compliance.

  10. Sign in says:

    Helpful tips! Great information and direction for a standard.

  11. Stifu says:

    The compatibility list makes the "default" standards behavior useless, since in the end, the vast majority of users will stay in IE7 mode. So Microsoft’s "change of heart" about enabling standards mode by default was no more than a PR stunt.

    Sites will only show in standards mode if they’re not in the compatibility list, or if they contain the IE8 meta tag… but otherwise, most users won’t bother unchecking the compatibility check box, so I wouldn’t count on it.

    My site is currently on a free host, which also hosts thousands of other sites all sharing the same domain name. And the compatibility list being based on domain names rather than sub-domain names, that basically means my site will be on the compatibility list forever, since most of the other sites hosted there will never be standards compliant. In other words, the default behavior of IE8 only benefits standards-friendly sites hosted on their own little domain (and then again, they might still appear in the compatibility list by mistake), and they’re a minority.

    The conclusion is that you need to add the IE8 meta tag on your sites to be safe, which leaves us in the exact same situation as if Microsoft hadn’t "changed its mind" about the default rendering mode of IE8. Only more confusing.

    Evan: you’re making it sound like IE8 doesn’t already have 3 rendering modes… It does. Quirks (IE 5.5), Compatibility (IE 7) and Standards (IE 8).

  12. Mike Morley says:

    RE: "Why would you assume that "sites found on corporate intranets" expect “IE” to act like IE7?"

    It seems strange to me that I create and test an application that is distributed on an intranet site,  setting it to IE8 standards mode. Then these settings will be over written based on:

    1. A user setting of a concept they are unlikely to understand or care about or

    2.  A blanket ‘checkbox’ to render ALL intranet sites in another mode. If I am building, testing and deploying surely I know best what mode the page should be rendered in!

  13. boen_robot says:

    @Mike Morley

    If you explicitly set the X-UA-Compatible HTTP header or meta equivalent, it is YOUR settings that will be honored.

    What those settings do is change IE8’s behaviour *in the absence* of such an HTTP header or meta equivalent.

    i.e. if "Display intranet sites in Compatability View" is checked (which it is by default) AND your page doesn’t say explicitly the engine to be used, it’s IE7 that will be used.

  14. Mike says:

    sorry off topic but is this get the facts campaign for real.

    http://www.microsoft.com/windows/internet-explorer/get-the-facts/browser-comparison.aspx

    The browser comparison chart is the funniest. I know it is marketing but it really comes across as childish.

    I will just quote two examples

    Developer Tools–Of course Internet Explorer 8 wins this one. There’s no need to install tools separately, and it offers better features like JavaScript profiling.

    Ha Ha Ha, am I the only developer who hasn’t stopped using firebug and now develops in IE8. Besides why is downloading the tool a bad thing, I don’t think the average user needs to use web dev tools.

    Web Standards–It’s a tie. Internet Explorer 8 passes more of the World Wide Web Consortium’s CSS 2.1 test cases than any other browser, but Firefox 3 has more support for some evolving standards.

    Make your own minds up on that one.

  15. Stifu says:

    Mike: thanks for the laughs, I missed this.

  16. Mike Morley says:

    @boen_robot

    Please correct me if I am wrong, but the situation is this.

    I have set the meta tag to "IE=8" as I want the "Browser Mode" to be IE8 standards.

    In: Tools > Compatibility View Settings, the default is "Display intranet sites in Compatibility View". It appears to me that this setting wins against my meta tag declaration, so regardless of my programming we are in compatibility mode and the user_agent is IE7.

    If I turn off this checkbox (for all intranet sites, not a selected list) then it will follow my meta tag declaration.

    I can see this causing real issues when deploying the application in company intranets.

  17. James says:

    I echo ShadowChaser’s comments.

    We build and support a business-to-business website. The last time we checked the stats we found that we have a surprisingly large number of users still running IE 6 (20%).

    We’re currently experiencing the same problem as this guy:

    http://groups.google.com/group/microsoft.public.dotnet.framework.aspnet/browse_thread/thread/9f7fd62f5f069566?pli=1

  18. Scott Dickens [MSFT] says:

    @Mike Morley

    The X-UA-Compatible tag does in fact "win" vs. Compatibility View on the client. http://blogs.msdn.com/ie/archive/2009/02/16/just-the-facts-recap-of-compatibility-view.aspx

    There are two things that may be going on –

    1. The X-UA-Compatible tag isn’t taking affect because it isn’t being used correctly. Double-check your syntax. Also, make sure that the tag is placed correctly. It must be included in the <HEAD> of the doc (assumes you aren’t sending it down via HTTP header) AND it must come BEFORE tags like <script> and <link>. http://msdn.microsoft.com/en-us/library/cc288325(VS.85).aspx. The reason is somewhat sound – IE needs to finalize the document mode before evaluating any item that may behave differently depending upon the document mode (version). To check all this, load up your page. Open the DEV Toolbar (F12)to check the resulting document mode. Also from within the DEV Toolbar, View->Source->Original to check X-UA-Compatible tag placement.

    2. You have code that’s pivoting on the User Agent string. The X-UA-Compatible tag affects the Document Mode, e.g. IE8 Standards, IE7 Standards, Quirks. It can’t affect the UA string as it’s already too late to change that – the client’s already made the GET request to the server (and it contains a UA string). What this means is that if your site pivots on the User Agent string, adding just the X-UA-Compatible tag won’t make your website work as expected – you’ll also need to update your User Agent string detection logic as well.

  19. Mike says:

    Hello IE team,

    I’m posting here because the official IE page has no way to contact.

    My question is this: can you please remove or correct this page:

    http://www.microsoft.com/windows/internet-explorer/get-the-facts/mythbusting.aspx

    That page contains several lies, which is not a good way to ‘inform’ people. I’m looking forward to the corrections. Or do you support spreading such lies?

  20. EricLaw says:

    @Mike: The page you’ve cited debunks a number of common myths which exist about web browsers.  Each of the points explains in detail why the claim is a myth.

  21. AndyC says:

    @evan: Why would you need to test in "faked IE7" mode? If the user has a browser capable of it, they’re running IE8 in which case you can serve them standards compliant code and force the browser into IE8 mode.

    The "fake IE7" is only there as a last ditch compatibility shim for pages that haven’t yet been updated.

  22. Christian says:

    Is there any real-world example of a page that triggers this kind of automatic fallback into IE7 land?

    How many such assertions that trigger fallback behavior are there in the IE8?

    IE8, like any browser, will probably still have some  bugs in its rendering engine. To me it’s a scary idea, if those send the whole site into the past. A message what went wrong would be a lot more predictable and would ensure that things will be fixed, even if it is a little frustrating for visitors.

    It’s scary that sane behavior does not come by default and instead has to be ensured with a proprietary HTTP header. Could you please get together with other browser vendors and at least agree on one single HTTP header, like:

     UA-Behavior=no-guessing

    If this parameter is active, then User agents should just take the site seriously: no compatibility modes, no content sniffing, not any such stuff, where the browser tries to be smarter than the site. If such can’t be the default behavior, then at least there should be a simple, cross-browser, version-independent way to opt in into the most reasonable and predictable client behavior that is available. For example, the HTML 5 WG could be a good place for agreeing on something like this (…that is, if MS where to take it seriously).

  23. DT says:

    I’m sorry, how can you consider putting temporary compatibility-set domains in parentheses to be anything approaching adequate?

    Kindly consider at the very least displaying something like

    (Temporary) viks.org

    Even that isn’t spectacularly user-friendly as people will not know what is meant by the entry being temporary, but it’s better than completely unexplained arbitrary markings.

  24. Dan says:

    DT: Your tone leaves something to be desired.

    They probably rightly consider it "more than adequate" considering that no normal human ever opens this dialog, and nearly no normal human ever encounters the sorts of of problems that lead to the temporary assignment of compatibility view in the first place.

  25. DT says:

    Is your implication supposed to be that all the abnormal humans read this blog so they’ll know what it means if they ever come across it?

    The only way in which an entry in a list clearly labelled as items the user themself has added which was actually added by the computer, which is wrapped in parentheses for no explained reason (and may be viewed to be the normal way for entries to appear, if there are no other entries in the list), can be considered "more than adequate", is if the only people who will ever see it are the people who designed it that way. Vaguely akin to what you said, but if that was the case then they wouldn’t be going out of their way to tell us about it.

  26. Jennifer says:

    How do I set up IE8 so that files opened from my localhost / 127.100.0.0 / 192.168.100.x / myservername

    open in IE8 in standards mode (BUT!!!) Also show me the compatibility mode button.  For testing pages it is really annoying to have to use the slow developer toolbar to make this switch and more importantly there is no VISUAL indication which mode I’m in.

    thanks

  27. Marakra says:

    how I know that in large companies still stands 6 version of your browser and it will not hinder