Dela via

Removing the IE9 Compatibility Button, and HTML1115 warning

  • Artikel

 

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?

HTML1115

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.

    1: <!DOCTYPE html>
    2: <html xmlns="https://www.w3.org/1999/xhtml" xmlns:fb="https://www.facebook.com/2008/fbml" xml:lang="en" lang="en" dir="ltr">
    3: <head>
    4:     <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    5:     <link rel="shortcut icon" href="favicon.ico" type="image/x-icon" />
    6:     <title>Home Page</title>
    7:     <meta http-equiv="X-UA-Compatible" content="IE=9">
    8:     <!--IE9 Install Time-->
    9:     <meta name="application-name" content="My Web Application" />
   10:     <meta name="msapplication-tooltip" content="Yeah, Yeah, Yeah" />
   11:     <meta name="msapplication-starturl" content="/" />

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:

image

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.

Comments

  • Anonymous
    March 28, 2011
    "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), " Seriously?  You're blaming the programmer here?  What happened to the whole "one markup" push, where one shouldn't have to add browser-specific stuff?  That's an utterly ridiculous statement, especially from an evangelist. "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." Now that's more like it.

  • Anonymous
    March 28, 2011
    GregM, I'm not sure I'd say that I'm blaming the programmer. We have lots of issues to deal with. Yes, we're trying to have a "one markup push", but that is not what this topic is about. IE compatibility is a complicated topic. If we only had to only support HTML4 or HTML5, life would be so easy. But, we have to take care of web developers with the various standards modes. We have to take care of consumers that are upgrading from various versions of IE. There are lots of variables. This is not a new ask either - it started in IE8. When it comes to X-UA-Compatible, there are 3 parties in this little play:

  • consumer, who can click on the compatibility button if the site doesn't indicate what standards mode
  • Microsoft, by way of the Compatibility View List
  • web site, by the meta entry or response header Out of this list of players, who best knows if a specific site's code is ready for IE9 Standards Mode? A: The developer. Is our story of IE perfect? No.  Is this an extra step that we're asking developers to do? YES. Is this a big effort? NO. So, this is why IMO the developer has a responsibility here. Does he have to? NO. The consumer won't know. But, you and I know that the developer could easily address this. And believe me, I want it to be easy. I want IE to be quality. And I think we're making excellent progress. But we still have room for improvement. And I see us continuing to move forward.