In IE9, the presence of the compatibility button means that a site is defaulting to IE9 Standards mode, and has not indicated what standards mode to run under. FYI – the compatibility button is the broken page image that appears in the address bar. To give the consumer a chance to correct the programmer’s non-communication (hasn’t heard of this feature, laziness, wants MS to fail, whatever), IE provides the button. The IE team keeps an eye on these clicks, and will investigate if a site should be added to the Compatibility View list. More importantly, it allows the consumer to have the site function – and not be turned off and blame the site experience on IE9.
Recently, I was working with one of our customers on site pinning. And we had the code done for a cool implementation, and were ready to deploy. As one last step, I ask the developer to do me a favor and remove the compatibility button – by adding a X-UA-Compatible entry in the HEAD section. If your site can run under this mode, then I like the button to get out of the way. And this is simple to do – just add the entry or the appropriate header. And the developer granted my wish, yet the compatibility button didn’t go away. What’s up?
Well, I’m supposed to be some type of expert (at least in my own mind). And I’m scratching my head. The page had the necessary (and IMO redundant) X-UA-Compatible entry (line8) – but that button is still there. I’m showing a similar snippet below.
So, just to make sure that I’m not missing something, I bring up the handy Developer Tools (F12 in IE) to look at the HEAD. Looks good.
Then I click on the SCRIPT to check to see if IE is displaying any warning. I highly recommend doing this for any site that you work on. You can learn all sorts of stuff about your site that you weren’t aware of. In this case, I got the following:
So, I can tell the IE9 is reacting to the entry – but what is this error code? Why would it ignore a meta line? I had to go ask because it wasn’t clear to me. And the story is: when other downloadable META resources are declared before a X-UA-Compatible entry is found, the document mode defaults to IE9 Standards Mode. In this case, you’ll see that line #5 has the favicon – and this is the culprit. Move the X-UA-Compatible line before this, and the problem goes away.
Problem solved, and lesson learned.
Warning: The Maturity of X-UA-Compatible
The site had a HTML5 doctype. And in my opinion, this should indicate that the site wants to run in IE9 Standards Mode (our most compliant engine yet) and NOT show the Compatibility button. But IE9 doesn’t do this. (Here’s a diagram of IE9’s algorithm for determining document mode.
You’ll find various schools of thought on this. Signaling the “document mode” with a X-UA-Compatible entry is intended to be for quick fix situations – where the developer needs to run in a previous mode (typically IE7 mode these days) and come back later to mature the code when they are ready. And some think that the DOCTYPE is the correct / mature way to indicate what you want to do.
And since HTML5 has a distinctive doctype and requires the IE9 Standards mode, I wish the compatibility button would NOT be displayed in these situations – and the developer wouldn’t have to take the extra step to remove the button. But that’s just me. In the end, you could just leave the button.
Common Compatibility Issues
I’ve mentioned this before, but I thought I’d point out something that my team is seeing a lot. When looking to see if your site can function under IE9 Standards mode, most of the time lately it’s been an overly aggressive usage with CreateElement. I have to chuckle when techies get onto us for lack of standards, but when we follow one then we get an evil eye again. So, check out The Compatibility Cookbook.
And if you’re experiencing issues, let us know.