IE8 is Microsoft’s most standards-compliant browser yet, which is awesome news… unless, of course, your web application relies on non-standard behaviors that previous versions of IE might have handled just the way you wanted. In other words, a giant leap forward for web-kind might be a step backward for you.
To help support existing sites, standards based and not, as well as new sites that subscribe to all of the latest standards, IE8 actually ships with two rendering engines, that of IE7 and the new improved layout engine in IE8. So how does IE know what to use and when?
To get some visibility into the process, I recommend you use the IE Developer Tools that ship with IE8; you enable the tools from IE’s Tools menu, or just use F12. There’s a number of cool things you can do with the tools, but of immediate use to us here is the detection of the Document Mode.
Note, there are three document modes listed:
- Quirks mode refers to pre-standards pages, essentially the rendering behavior of IE 5
- IE7 standards mode refers to IE7’s handling of standards mode
- IE8 standards mode refers to IE8’s handling of standards mode.
Quirks mode is triggered if the page contains no
<!DOCTYPE> declaration or one that is insufficient to trigger standards mode. For instance, a page with the following markup would render in quirks mode:
<html> <body> <h1>Hello World</h1> </body> </html>
From the document mode list above, you can see there are two standards modes: the current up-to-date IE8 version, and the version of the standards that were supported with IE7. As you might expect, standards are evolving and advancing as time goes on, so what was standard when IE7 was released is not necessarily what’s defined as standard today.
We know now that a page is displayed in standards mode if there is an appropriate
<!DOCTYPE> declaration, but when is a page displayed in IE7 standards mode versus IE8 standards mode?
The general rule is that IE8 standards mode is the default, so if the site is not a quirks mode site, it will opt for IE8 standards mode over IE7 (with some exceptions… read on).
Compatibility View – Fixing It Up on the Client
Of course, every rule has exceptions, and that’s where the compatibility view options come in. Out-of-the-box, IE8 is configured so that standards-mode sites in the Intranet Zone (except for localhost) will default to IE7 standards mode, and sites in the Internet Zone (and localhost) will default to IE8 standards mode.
This combination of settings allows public sites to immediately take advantage of the advancements in standards compliance of IE8, but not risk the breakage of internal applications that may not work well with IE8, or conversely, put additional pressure on internal applications to immediately comply with IE8.
As you might expect, you can control this default behavior, namely via the Tools>Compatibility View Settings dialog from within IE8. Here, you can choose to display (or not) Intranet sites or all websites in Compatibility View.
Or, for finer granularity, you can select specific sites to add to the list. You can add them manually via the dialog to the left, or use the Compatibility View button on the browser shown below.
The button is only displayed for sites that are defaulting to IE8 standards mode, so you won’t see it all the time. If you enable compatibility view for a particular URL, it applies to all pages in the domain of the current page.
In addition to the end-user’s calling the shots, Microsoft also maintains a list of high profile sites that do not render properly in IE8 standards mode and ships this list with the browser. You can view the list installed with your browser by browsing to the URL res://iecompat.dll/iecompatdata.xml (assuming you elected to include it when installing IE8). If a page at one of these domains is accessed, IE8 automatically switches to IE7 Standards mode. Microsoft is actively working with these site owners, so the list of such sites will shorten over time. The updated lists are pushed out periodically via Windows Update, so you will automatically get any improved behavior without modifying client settings.
If you’re ever in doubt of what mode the page is using, refer to Document Mode as shown the IE Developer Tools menu bar (see image above). You can modify the rendering by switching modes in the dropdown menu, which causes a refresh to reflect the selected mode.
X-UA-Compatible – Fixing It Up at the Source
While it’s great that the end-user has some flexibility on viewing the site in different modes, first impressions are the most important, so the goal of the web site developer should be to provide the smoothest initial experience.
The end goal, of course, for you as a web developer is to achieve IE8 compatibility ‘natively’, but you obviously want to do so on your schedule, not Microsoft’s! To support you in this goal, you can include a
meta tag with an
http-equiv attribute of
X-UA-Compatible in the HEAD section of your web pages, for example:
<meta http-equiv="X-UA-Compatible" content="IE=7"/>
The predefined content values and their interpretations are shown in the table below. You can determine the compatibility mode in your client-side logic as well by using the
|IE=5||5||quirks mode as displayed by IE7|
|IE=7||7||standards mode as interpreted by IE7|
|IE=8||8||standards mode as interpreted by IE8|
|IE=EmulateIE7||7||standards mode as interpreted by IE7 or quirks mode if so determined by
|IE=EmulateIE8||8||standards mode as interpreted by IE8 or quirks mode if so determined by
|IE=Edge||8 (for now)||highest mode available (currently equivalent to IE8)|
The values are not mutually-exclusive, and you can actually include values not in the list above to help ensure your pages maintain consistent behavior in future browser versions.
So, as an example, using the IE Developer Tools you can ascertain that the imdb.com site (as of this writing) uses the
X-UA-Compatible tag with a value of EmulateIE7 to switch the browser into IE7 standards mode.
This approach works well if you have only a few pages that aren’t yet up to IE8’s level of standards compliance, but if you’ve got a site full of such pages, or you want to defer the work necessary to confirm IE8 compatibility across your site, you can set a custom header to apply across multiple pages. In IIS, for instance, you can add the following configuration information to the
web.config file at the machine, site, application, or directory level to have all pages rendered in IE7 standards mode.
For more details on configuring the headers on your web server, see the following resources:
Note, that a setting at the individual page level will override the mode specified by the server. Likewise, a setting included in the page (or site) will override the Compatibility View setting discussed in the previous sections.
So what should be your plan of action? While there’s no one recommendation that will apply across the board, here’s some general advice:
- Test your site with the default settings, namely without Compatibility View engaged or a
X-UA-Compatiblemeta tag but with a standards based
<!DOCTYPE>.This will help flush out any IE8 specific issues.
- Fix the issues that you discover to gain native IE8 compliance, but if you currently don’t have the bandwidth to make the fixes,
IE=EmulateIE7on breaking pages, or if you have a lot of breaking pages,
IE=EmulateIE7at the directory, application, or server level as needed.
- Expect the client to know about Compatibility View or expect them to engage it (remember, first impressions are key!)
- Rely on
X-UA-Compatibleas the long-term solution. For instance, the browser will still report itself as IE8, so code that keys off the User Agent string to generate and deliver content may still require some updates.
Next week: Detecting Browser Modes