XING Devblog

Against IE8′s Compatibility View: from Stagnation to Standards

| Posted by

Compatibility View for IE8

Microsoft introduced Compatibility View for IE8 in accordance with their “Don’t break the web”-maxim. Previous versions of Internet Explorer did not follow web standards, IE’s development seemingly came to a standstill, consequently frontend engineers used an awful lot of workarounds to fix the non-standard rendering. However, IE8 follows the standards, and the old workarounds caused many sites to break – hence Compatibility View. In Compatibility View, IE8 renders a page like IE7 did. This was meant as a helper for pages that were not updated yet.

Meanwhile, Compatibility View became a cause of stagnation: Sites will likely be slow to update their strategy, keeping IE in Compatibility View. Most big sites run their pages in Compatibility View nowadays, because “it just works” in IE7, and because the costs to re-engineer and to re-test the pages are fairly high. In contrast, the benefits of using Standards View in IE8 are not obvious; performance, of course – but you cannot measure that until you try it.

Browser Mode and Document Mode

There are two modes that rule Compatibility View: browser mode and document mode.

Browser mode is to be set in the Compatibility View settings by the user and via a list hosted by Microsoft. This Compatibility View List is distributed via Windows Update to the IE8-client. XING used to be on the list, but was removed by Microsoft, so some users will land on XINGs platform in compatibility browser mode, some in standards browser mode. Although Microsoft doesn’t make this clear, site owners have to opt-in to standards mode because of the ever-changing Compatibility View List.

Document mode can be set set by the site owner: as a meta-flag in the HTML document or as a response header by the server. XING used to set the document mode via <meta http-equiv="X-UA-Compatible" content="IE=7" /> in the HEAD section of your HTML documents.

For the beta-test migration to IE8 standards mode, we removed that meta tag. To set the document mode, our servers answered with a response header instead:

  • X-UA-Compatible” “IE=8” for XING developers and
  • X-UA-Compatible” “IE=EmulateIE7” for all other users.

This server-side switch allows for forking depending on the IP-address.

Again, you cannot rely on leaving the response header or meta tag unset because you cannot exactly know what Compatibility View List settings the browser is using. Users may or may not have used Windows Update recently; and a third party controls the list.

Fig.1: Analysis of IE8 browser mode set for Alexa’s Top 100 Sites (Nov. 2009). More than 50% are set via the Microsoft-hosted Compatibility View List.

Fig. 2: Analysis of IE8 document mode set by Alexa’s Top 100 Sites (Nov. 2009). Quirks mode: Without a standards-mode-doctype. IE7-Standards: Render mode set via Response-Header, Meta-Tag, or Compatibility View List. IE8-Standards: One of the mentioned trigger or no trigger at all. Only 30% use the most standards adherence mode.

Beta Test Findings

Our internal beta tests revealed a couple of problems:

  • Bug with vertical-align: text-top for inline elements in our transitional doctype (solution: ie8-specific workaround, since MS stated that they will not fix it for IE8)
  • Bad hyphenation in some texts: ‘Nicht-\nMitglieder’ becomes ‘Nicht\n-Mitglieder’ (solution: won’t fix)
  • Prototype JavaScript library had to be updated when available (solution: update)
  • User-Agent sniffing breaks for those users that had the old Compatibility View settings. They land with an IE7-like User Agent, receive the response from the server, and proceed with a IE8 User Agent string. (Solution: User Agent sniffing on a pre-sanitized User Agent string.)

“Haha. So, you are coming from IE6/7-specific workarounds and got IE8-specific workarounds in addition?” This is partly true. On the other hand, we gained a lot more standards compliance and run a comparatively small set of workarounds, with the benefit of better performance for a growing set of users who switched to IE8. More users are getting less workarounds.

Performance Results

Because there is no need to serve IE7-related workarounds to IE8 any more, the amount of loaded CSS rules per page decreased significantly, and we saved one HTTP-request on every page load. The page load times (Page loaded, Dom loaded, Interaction ready) are better – measured and perceived. IE8 was known to be faster than its predecessors, and we could measure it on-site, not just on laboratory conditions.

Was it worth it?

Yes, definitely. We stopped using a comfortable mode that meant a dead-end-street for development, and we got measurable benefits for our users.

About the author

Ingo ChaoIngo Chao is Manager Quality Assurance with a background as a front-end engineer at XING. He wrote a book on CSS, and he frequently contributes to the css-d mailing list. XING Profile »

Tobias OtteTobias Otte polishes CSS and markup for the Frontend Engineering Team at XING. He finds his interest piqued by the likes of accessibility, semantics, and usability. XING Profile »


4 thoughts on “Against IE8′s Compatibility View: from Stagnation to Standards

  1. Hello Ingo,

    “Compatibility View became a cause of stagnation: Sites will likely be slow to update their strategy, keeping IE in Compatibility View. Most big sites run their pages in Compatibility View nowadays, because “it just works” in IE7, and because the costs to re-engineer and to re-test the pages are fairly high. In contrast, the benefits of using Standards View in IE8 are not obvious; performance, of course – but you cannot measure that until you try it.”

    Correct deduction in my opinion. What’s the benefits to upgrade? How much would that cost, involve in time/energy/testing? Fair, rational, reasonable and responsible questions.

    The whole complex system of compatibility view, backward-compatibility and compatibility for IE versions create no incentive, brings no support, no assistance, no motivation, no (apparent) reward to upgrade (toward web standards compliance) webpages or websites. This is what I clearly had in mind last year:

    IE 8 final and compatibility view switch mode: some Chris Wilson answers
    http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/ie8-final-compatibility-view-chris-wilson.html

    Such complex, dedicated IE compatibility system creates a permanent crutch for old, broken, buggy IE (6 & 7) versions still in use out there. This compatibility triggering system was supposed to help web authors, webmasters during a temporary, transitory period but it now looks more and more as a critical ingredient in a permanent strategy on how to serve/deal with IE users… without having to adjust or to upgrade a website.

    “Although Microsoft doesn’t make this clear, site owners have to opt-in to standards mode because of the ever-changing Compatibility View List.”

    Another proof and demonstration that “Render websites in the most standards compliant way by default.” commitment is far from obvious, has a lot of holes, exceptions, protocols, hoops, if/but/unless/otherwise clauses, etc..:
    IE Compatibility List Pruning
    blogs.msdn.com/ie/archive/2009/07/01/ie-compatibility-list-pruning.aspx

    “Bad hyphenation in some texts: ‘Nicht-\nMitglieder’ becomes ‘Nicht\n-Mitglieder’ (solution: won’t fix)”

    You are not alone! Jukka Korpela reported this precise issue several months ago:

    Word division problem:
    IE 8 may split before a hyphen
    http://www.cs.tut.fi/~jkorpela/www/hyphens.html

    I believe, just a hunch, this is related to

    http://jhop.me/tests/bugs/ie8/whitespacenoderendering.html

    http://www.css-lab.com/misc-test/ie8-last-child-node.html

    and was reported at

    https://connect.microsoft.com/IE/feedback/details/472846/unexpected-white-space-child-text-node-inserted-after-last-child-inline-level-elemen

    best regards, Gérard Talbot

  2. IE is such a piece of junk. I don’t know why smart people continue to use it. 8 isn’t much better than 7 and the compaitibility view breaks more sites that work than it fixes. FireFox, Chrome and even Safari render pages better.

    I’ve seen 9 and it has a LONG way to go. Just ditch it. Why wait for a better IE when other great browsers already exit.

  3. There is one huge drawback with compat. view and that is that it indeed does NOT render pages like the native version does. IE8 compatibility view does not render pages in the same way as native IE7 did. So instead of getting a new browser to support in IE8 we got two, IE8 and IE8 compat. view. Thanks MS!

Leave a Reply

Your email address will not be published. Please fill out the required fields.

  • You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>