The nightmare that is IE

If you ask any web designer what would constitute their dreams coming true, they will probably say something along the lines of “Internet Explorer vanishing from the face of the earth, never to be seen again”. Web development has for many years consisted of building your beautiful online creation and then polluting it with all kinds of hacks to get around the bugs and quirks in the various versions of IE.

We’ve just run into a nice issue with IE8, where a site running on our intranet will render completely differently from a deployed site running on a public server. The HTML and CSS is identical, it’s just that IE recognises that one is in the intranet zone and, for some completely unfathomable reason, decides that it should therefore be displayed differently.

For any sysadmins who haven’t yet replaced IE on their users’ desktops, this helpful page by Henri Sivonen gives a hint of the problems that you are helping to perpetuate. This is not a rant, it’s a useful guide to what designers have to think about, just to make their pages display properly, because you’re not using Safari, Firefox, Opera or Chrome.

An excerpt:

IE8 has four modes: IE 5.5 quirks mode, IE 7 standards mode, IE 8 almost standards mode and IE 8 standards mode. The choice of mode depends on data from various sources: doctype, a meta element, an HTTP header, periodically downloaded data from Microsoft, the intranet zone, settings made by the user, settings made by an intranet administrator, the mode of the frame parent if any and a UI button togglable by the user. (With other apps that embed the engine, the mode also depends on the embedding application.)

The lucky thing is that IE8 uses doctype sniffing roughly like other browsers if:

  • There is no X-UA-Compatible HTTP header set by the author.
  • There is no X-UA-Compatible meta tag set by the author.
  • Microsoft has not placed the domain name of the site on a blacklist.
  • An intranet admin has not placed the site on a blacklist.
  • The user has not pressed the Compatibility View button (or otherwise added the domain to a user-specific blacklist).
  • The site is not in the intranet zone.
  • The user has not chosen to display all sites as in IE7.
  • The page is not framed by a Compatibility Mode page.

For the points other than the two X-UA-Compatible cases, IE8 performs doctype sniffing like IE7. The IE7 emulation is called Compatibility View.

In the X-UA-Compatible cases, IE8 behaves radically differently from other browsers. Please see an appendix on this page or a flowchart available in PDF and PNG formats.

Unfortunately, without an X-UA-Compatible HTTP header or meta tag, IE8 lets the user accidentally drop you from the IE8 standards mode to the IE7 mode that emulates the standards mode of IE7 even if you used a proper doctype. Worse, an intranet admin may do this. Also, Microsoft may have blacklisted the entire domain you use (e.g. mit.edu!).

To counter these effects, a doctype isn’t enough and you need an X-UA-Compatible HTTP header or meta tag.

God help us.

Enjoyed this post? Why not sign up to receive Status-Q in your inbox?

1 Comment

Great post ! All so far far away from the original vision of Tim Berners-Lee 🙂

Got Something To Say:

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax

*

© Copyright Quentin Stafford-Fraser