Since Internet Explorer (IE) 8 Microsoft have supported a ‘Compatibility View’, allowing users to view web pages as if they are using a lower version of IE, normally IE 7. It appears in the top right of IE 8, 9 and 10, stating that it will make websites designed for older browsers look better. This has now been hidden in IE 11 (preview) but the functionality still exists through the menu tools.
For me this is where the questions/problems start. What older browsers? Why would new versions of IE not be backwards compatible? If I use this am I going to loose any functionality the new browser offers? Will it look and act exactly the same as when viewed in a native browser it is trying to emulate? Why does this not appear on all websites?
This post will aim to remove all of these uncertainties regarding IE’s Compatibility View and detail how as developers we can control this behaviour using the ‘X-UA-Compatible’ meta tag or header.
When the default Compatibility View is enabled manually in either IE 8, 9 or 10 by clicking the icon on the address bar, the browser will attempt to behave as if you were in IE 7. When the browser attempts to emulate IE 7 it will:
- Use IE 7 Standards mode for standards mode document
- Send the IE 7 User agent string
- Sets the right internal parameters to process conditional comments as IE 7 would.
The site will be added to the Compatibility List accessed through the tools menu of each browser. It is worth noting that the site is added based on the domain name, excluding any sub domain or URL path, meaning that any site hosted on that domain will be displayed in Compatibility View until removed from this list.
The default setting has Compatibility View enabled for all intranet sites only, with a setting to enable it for all sites. But what does ‘Download updated compatibility lists from Microsoft’ exactly mean? After some research I discovered Microsoft collates a list of high volume sites where users turn on Compatibility View, and this option will download that list and enable Compatibility View automatically when using these sites. If you want to know more the IE Support Team wrote a blog about the list and on the support site there is a description of how it is compiled.
So as developers we want to support as many browsers as possible, with Compatibility View available on your site the number of IE versions has increased by 3. This is a burden on development, testing and to be frank is just completely over the top. The only way to tackle this issue is to be in control of how your site behaves.
We can control how IE Compatibility View will behave through the use of a meta tag or custom header. Using any of the below options will hide the compatibility view icon from the user and handle the page as dictated.
<meta http-equiv="X-UA-Compatible" content="IE=9; IE=8; IE=7">
The meta tag has to be placed in the head tag, and can only be preceded by the title. If you place any other tags such as <style> or <script> before the meta tag it will not recognize your tag and revert to the default behavior.
IIS 7 Custom Header
<system.webServer> <httpProtocol> <customHeaders> <add name="X-UA-Compatible" value="IE=edge" /> </customHeaders> </httpProtocol> </system.webServer>
A complete list of custom headers has been posted on stack overflow. The possible values that can be used as the value/content are listed below.
- “chrome=1″ – The browser will use chrome frame if it is installed and will override any of the settings above (now discontinued)
This tells the browser which version of IE you wish your site to be rendered in. These can be used individually or together. If multiple options are provided the highest one for the active browser will be used. If a single value is provided it will be used, unless it is not available and then the active browsers standard will be used. If you prefix the version number with ‘Emulate’ and have no doc type this implies quirks mode, if you would like more details about the different modes Microsoft have described exactly how each of these behave.
On a new site I would always use IE=edge as it will render the site in the newest possible version of IE and remove any uncertainties by hiding the compatibility view icon. However Microsoft does not recommend this and instead suggests just having a HTML 5 doc type, which will force your website into standard mode. The HTML 5 doc type will not hide the compatibility view button and is the reason I still include the meta tag with edge.
For sites that have been active without any X-UA-Compatible defined it is not that simple. Users may have already enabled Compatibility View and may have even been encouraged to use this view until the site supported newer browsers. You can still provide the X-UA-Compatible information and it will force the page out of Compatibility View and hide the icon. I have recently discovered that it does not completely force the site out of Compatibility View.
Agent String Bug
I have used two indicators to identify if the browser has been forced out of Compatibility View, ‘document.documentMode’ and the content of the agent string.
Using these I documented the behavior in the standard mode with Compatibility View on, then with it on prior to adding U-XA-Compatible information, and finally with it off prior to adding added U-XA-Compatible information.
The results are very concerning when Compatibility View is on prior to implementing the U-XA-Compatible information. It appears that the browser is rendering the page in the active browser version, yet the agent string is still indicating that Compatibility View is on. The user will likely see no difference, but this is a serious issue. This will cause any server side logic that is browser specific to run incorrectly, as well as misreporting in any web server logs. I have not seen this issue reported anywhere else and came up with two solutions.
The first and most simple solution is to manually remove the domain from the Compatibility View List found under Tools, Compatibility View Settings. The agent string will now report correctly. This requires every user that had Compatibility View on to take this action, I think this may be unrealistic.
The second option is to have a page on your site (preferably a login page if you have one) where the meta tag has not been included. We can use ‘document.documentMode’ to see if Compatibility View is on (if it equals 7 it is on) and then display a message to the user informing them that ‘Compatibility View is not supported on this site’, or even block them from taking any action until they turn this off. I went with the option to allow the user to continue but warned them strongly against it, I did this because some users (such as corporate) do not have complete control of the Compatibility View List.