IE Compatibility List Pruning

[Guest NewsBot]

Hi, I am Michael Benny, a tester on networking in Internet Explorer. During the Internet Explorer 8 development cycle I was responsible for verifying many of the pieces of Compatibility View. We have discussed earlier about how the Compatibility View feature works and the steps a site author can take to ensure the Compatibility View button never displays for IE8 users visiting your site. There is another scenario that we have not yet covered, if my site was already added by an End-user to their Compatibility View list before my site was updated, and now it’s ready, how would I get the site off of that user’s list? I wanted to share one particular feature that we haven’t blogged about before – the ability to “trim†domains from a user’s Compatibility View list.

 

As a quick refresher on Compatibility View, Internet Explorer 8 uses its most standards-compliant rendering behavior by default. This configuration may cause problems with websites that expect the older, less interoperable behavior from IE. As a site administrator, you have a number of tools at your disposal to ensure IE8 clients have a compatible experience with your website – taking advantage of the standards improvements in IE8 or using the X-UA-Compatible header to tell IE8 “display content as IE7 would have†being the two most common options site authors have requested.

 

End-users also have a way to mitigate compatibility issues they may encounter in the course of normal browsing on sites that do not have the X-UA-Compatible option explicitly set. They can choose to view a site in Compatibility View, an IE7 emulation mode, by toggling a button on the browser’s address bar. Internet Explorer 8 remembers Compatibility Button presses on a per-domain basis in order to provide a more seamless return-visit experience. These domains are stored in a registry location on the client at HKCU\Software\Microsoft\Internet Explorer\Browser Emulation.

 

When a site is in a user’s Compatibility View list, the default document rendering behavior will be set to IE7 Emulation mode and it will affect the User Agent String used to request pages. As a site admin, you are always in control of how your site is displayed. Using the X-UA-Compatible tag, you can override Compatibility View on the client and dictate the exact rendering mode your site should be displayed in. Site admins also have the option to deploy the X-UA-Compatible header for a large section of pages as an HTTP header (Example: IIS and Apache). You can take this one step further by using the X-UA-Compatible to also remove your domain’s entry from the user’s Compatibility View list. Here’s how…

 

For a domain to be trimmed, the End-user must first land on a page with the X-UA-Compatible Meta tag or HTTP Header. The presence of an IE8 tag does indeed trigger the list clean-up process, but that’s not all there is to it. The next step is to look for a file called ‘IEStandards.xml’ placed at the domain root. IE will first make an HTTP HEAD request for this file looking for its presence. Absence of the file means that the domain remains in the user list. If the HEAD request is returned successfully, then IE will perform an HTTP GET request for the file. In the file, a tag called ‘IE8StandardsMode’ signals the list entry is really ready to be trimmed. Here is an example of the correct server configuration for ‘example.com’:

 

1. Set the page X-UA-Compatible header set to a value indicating IE8 mode
   
2. Place a file at the root of the domain ‘example.com’
   http://example.com/iestandards.xml
3. The file should have a root XML element called IE8StandardsMode:
   

Site admins should be aware that this affects all sub-domains. So if a user visits a page at ‘support.example.com’, which is configured as shown here, but there is another sub-domain like ‘mail.example.com’, which would still like to respect the user’s choice to put the site into Compatibility View, then the ‘mail’ sub-domain will use IE8 Standards mode rendering.

 

 

 

The entries on the Compatibility View list reflect an entire domain, example: ‘example.com’, rather than subdomains like ‘mail.example.com’ and ‘support.example.com’. IE must process the request to trim the domain entry from a source that represents the entire domain, otherwise side effects to subdomains may occur. As an example, suppose the entire ‘example.com’ domain is on the user’s Compatibility View list. Later, ‘support.example.com’ does great work to update their site to support IE8 and includes a HTTP header / tag indicating that portion of the site is best viewed in IE8 Standards Mode. ‘example.com’ and ‘mail.example.com’ have still not been updated. If IE were to remove the entry for ‘example.com’ from the user’s list based solely on the presence of the HTTP header / tag value found at ‘support.example.com’, the user could encounter a compatibility failure when they visit non-updated content at ‘example.com’ or ‘mail.example.com’. Checking for the ‘IE8StandardsMode’ file at the root domain level solves this case by requiring that someone “authoritative†for the domain signal list cleanup. That way, IE users can be assured of a consistent compatibility experience on the domain.

 

Getting the IESettings.xml file follows a very similar model to how IE will request favorite icons for domains, but we wanted to address the issue of server overhead. To avoid IE8 making multiple and unnecessary requests to a server for this file on every page navigation with the X-UA-Compatible option set, there exists a 30 day timeout period since the last request. This 30 day timeout period is also set when a user adds a domain to their user list, so do not be alarmed if you still see IE8 Compatibility View requests after deploying the file to the domain root.

 

 

 

Thanks,

Michael Benny

IE Test

 

 

More...

Edited March 17, 2014 by AWS