Original:
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.
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 IE
[(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
