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:
IE=8” for XING developers and
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-topfor 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)
- 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.
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.