views:

4638

answers:

4

For our web application, we are sending the X-UA-Compatible -> IE=EmulateIE7 for all the pages. However, the Compatibility View Button next to the Refresh button, is still displayed.

1) Is this expected behaviour? 2) Shouldn't the HTTP header force the browser to display in IE7 mode (with Quirks + IE7Standards enabled), and then now show the Compatibility View button?

If a site is not IE8 ready, is there a way to force IE7 emulation, and thus disable this button?

+10  A: 

According to Just The Facts: Recap of Compatibility View you've declared [your website] "ready" for Internet Explorer 8 through the use of the versioning tag. The Compatibility View button should not be displayed:

Site owners are always in control of their content. By default, Internet Explorer uses DOCTYPE switching to determine Quirks v. Standards mode (again, Standards mode maps to IE8 Standards by default). Site owners can choose to use the X-UA-Compatible tag to be absolutely declarative about how they’d like their site to display and to map Standards mode pages to IE7 Standards. Use of the X-UA-Compatible tag overrides Compatibility View on the client.

Sometimes the Compatibility View button isn’t displayed. The button is located on the address bar next to the ‘stop’ and ‘refresh’ buttons. There are a few cases where there’s no action for a user take and, thus, the Compatibility View button will not show:

  • If you're viewing an internal-to-Internet Explorer page (such as about:InPrivate)
  • If you're viewing a page that has declared it's "ready" for Internet Explorer 8 through use of the versioning tag / HTTP header (it doesn’t matter if this tag triggers Quirks, IE7 Standards, or IE8 Standards, the button won’t be displayed)
  • If you're viewing an intranet page and you have the ‘Display intranet sites in Compatibility View’ checkbox selected
  • If you're viewing any webpage and you have the ‘Display all websites in Compatibility View’ checkbox selected
  • If you're viewing a webpage that is included on the Microsoft-supplied compatibility view updates list and you have the ‘Include updated website lists from Microsoft’ checkbox selected
  • If you've toggled either the ‘Document Mode’ or ‘Browser Mode’ settings via the Developer Toolbar

If you're using an HTTP header, have you used Fiddler to verify that the X-UA-Compatible header is actually being delivered on every page?

If you're using a META tag, then according to META Tags and Locking in Future Compatibility:

The X-UA-compatible header is not case sensitive; however, it must appear in the Web page's header (the HEAD section) before all other elements, except for the TITLE element and other META elements.

Lastly, is IE8 actually in Compatibility View when the button shows up? If so, it is possible that your website is in IE8's compatibility list from Microsoft, or in the local client configuration:

  • Tools > Compatibility View Settings
  • Ensure your site isn't listed under Websites you've added to Compatibility View
  • Try unchecking Include updated website lists from Microsoft and restarting the browser
Grant Wagner
i have confirmed using Fiddler that all pages are getting the header and "Developer Tools" also confirms that the right "Quirks" or "IE7 Standards" mode document modes are being used on the site, always. But the compat button still shows up.META is not an option - the site is quite big, and we would like to control this setting at the site HTTP Response Header level.
Nishith
Thanks! This is a fantastic answer and the question author really needs to accept it!
cowgod
A: 

I found good info here also http://support.microsoft.com/kb/968499

metal-gear-solid
A: 

I had an issue on our workwear site whereby, we initally had to use the Meta EmulateIE7 to overcome CSS issues when IE8 was first released. We later rectified the problem and added the meta tag X-UA-Compatible IE=8

What we noticed is, even when clearing the browsers cache IE8 still retained the state of the compatibility button set by the user. It was important for us to overcome this because it was causing scripting issues when running in compatibility mode.

We solved the problem by having X-UA-Compatible IE=8 in the head of all pages and also adding it to IIS as a HTTP Header. The compatibility button no longer shows on visitors browsers =)

Hope this helps!

John Doherty
A: 

an opinion about giving up on older browser support: http://www.properdev.com/blog/post/BrowserWarsAndIECompatibilityView.aspx

anon