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 https://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.

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.

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

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.

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.

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

• Anonymous
  June 17, 2009
  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.

• Anonymous
  June 17, 2009
  What I don't like about the campatibility view is the time it takes to reload your site in the browser.

• Anonymous
  June 17, 2009
  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.

• Anonymous
  June 18, 2009
  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.

• Anonymous
  June 18, 2009
  The comment has been removed

• Anonymous
  June 18, 2009
  The comment has been removed

• Anonymous
  June 18, 2009
  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.

• Anonymous
  June 18, 2009
  Why would you assume that "sites found on corporate intranets" expect “IE” to act like IE7?

• Anonymous
  June 18, 2009
  @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.

• Anonymous
  June 18, 2009
  Helpful tips! Great information and direction for a standard.

• Anonymous
  June 18, 2009
  The comment has been removed

• Anonymous
  June 18, 2009
  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!

• Anonymous
  June 18, 2009
  @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.

• Anonymous
  June 18, 2009
  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.

• Anonymous
  June 18, 2009
  Mike: thanks for the laughs, I missed this.

• Anonymous
  June 18, 2009
  @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.

• Anonymous
  June 19, 2009
  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

• Anonymous
  June 19, 2009
  The comment has been removed

• Anonymous
  June 19, 2009
  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?

• Anonymous
  June 19, 2009
  @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.

• Anonymous
  June 20, 2009
  @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.

• Anonymous
  June 20, 2009
  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).

• Anonymous
  June 21, 2009
  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.

• Anonymous
  June 21, 2009
  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.

• Anonymous
  June 22, 2009
  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.

• Anonymous
  June 25, 2009
  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

• Anonymous
  June 25, 2009
  how I know that in large companies still stands 6 version of your browser and it will not hinder