michael orlitzky

Why X-UA-Compatible is stupid

Note: this article is old as shit.

Recently, Microsoft announced on the IE Blog that IE8 will have three different rendering engines. It will have the IE6 engine (both standards-compliant mode and not), IE7's engine, and a new standards-compliant engine for IE8. The standards-compliant IE8 engine should be, if Microsoft is to be believed, on par with other standards-compliant rendering engines such as Gecko and KHTML.

whoops, there's a massive catch

In order to enable the new standards-compliant rendering engine in IE8, you will need to do one of two things:

  1. Have your web server send an X-UA-Compatible HTTP response header along with the page. This can at least be done on the server level, and would only need to be done once.
  2. Add an http-equiv meta tag to each and every web page you create:
    1
    2
    <meta http-equiv="X-UA-Compatible" content="IE=8"></meta>
        

why it's stupid

There are a number of reasons why this is a bad idea. First of all, it doesn't fix the problem that it's intended to fix. Broken pages will remain broken, and people will continue to have to waste time and money making their sites work in Internet Explorer. It will also penalize designers and browsers that do adhere to the standards.

Everyone else has already noticed that it's stupid for these reasons, though.

why it's more stupid

There's another reason why this is a bad idea, and it's a reason that I haven't seen anyone else mention. Most of the arguments that I've seen that are sympathetic to Microsoft have concluded that while it would be unreasonable to add the meta tag to all of your pages, it would be easy enough for a savvy web designer to configure his or her web server to send the appropriate HTTP response header.

Consider this scenario, however:

  1. A standards-aware web designer configures her web server to always send the X-UA-Compatible HTTP response header, since she knows that all of her pages conform to web standards.
  2. An IE8 user visits one of the pages hosted on that server, and receives something like the following as a response:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    HTTP/1.x 200 OK
    Date: Wed, 23 Jan 2008 04:05:36 GMT
    Server: Apache
    Keep-Alive: timeout=15, max=100
    Connection: Keep-Alive
    Transfer-Encoding: chunked
    Content-Type: application/xhtml+xml; charset=utf-8
    X-UA-Compatible: IE=8
        
  3. As a result, the user's browser, IE8, displays the page in a standards-compliant manner (I am assuming for the sake of my argument that Microsoft won't screw up standards mode again).
  4. The user wants to save the page so that he can read it offline later. He chooses File→Save from the menu, and saves the plain (X)HTML page to his hard drive.
  5. Later, when the user goes to read the page, it looks like crap. Saved means no web server. No web server means no HTTP. No HTTP means no HTTP headers.

Basing the display of the page on the HTTP response headers is completely, ultimately, mind-bendingly retarded. The response headers are not part of the web page, and will not be saved along with it when the page itself is saved.

The http-equiv meta tag would be saved along with the page. However, no one is going to add meta tags to every goddamn page they've ever created, and update these meta tags each time a new version of any browser is released. Even the sympathetic responses to this idea agree that meta tags would be entirely unwieldy.

here we go

Wait! There's an easy solution! Just make Internet Explorer...

  1. Retain the HTTP response headers in memory
  2. Add the appropriate meta tag to any page that is saved

That way, if the saved page is ever viewed in the future, it will look the same as it did when it was saved. But only in Internet Explorer. All bets are off for other browsers. Furthermore, I don't want Microsoft screwing with my web page just because a user decided to save it.

In addition, there are a number of situations where it would be important that a page be saved exactly as it was received. Adding meta tags where they don't belong sort of poops directly on top of that parade. I'm selling that metaphor, by the way.

And just what do we do if the HTTP response headers disagree with the meta tags? Hmm?

This is great for Microsoft, and terrible for anyone who develops anything that is standards-compliant. At the very least, it would require every standards-compliant browser to implement this feature exactly how Microsoft ultimately implements it. If they don't, they risk incompatibility. Incompatibility with the de-facto standard, not the real standard.

Isn't that what we're trying to fix, guys? This question is not so much directed at Microsoft as it is to everyone else on the planet.

what about acid2?

Off-topic, but what the hell.

Microsoft made a big deal a couple of weeks ago about the fact that its new IE8 engine could properly render the ACID2 browser compliance test suite. As the Wikipedia page properly notes, no the fuck it don't. Nothing will be rendered in a standards-compliant manner unless you add this dumbass header to your server config, and that includes ACID2 and every other test suite.

Maybe the ACID2 folks should take the time to go back and retrofit all of their test pages with an IE-specific meta tag, and then spend hours re-testing and verifying that the test suite remains correct as a result. On a more personal note, my birthday is coming up in a few weeks, and I'd really appreciate it if you'd check out my wish list.