Internet Explorer 8 Compatibility Test Guide

Testing and designing for the Internet Explorer 8 browsing experience on your Web site

As of December 2011, this topic has been archived. As a result, it is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Internet Explorer, see Internet Explorer Developer Center.

Hans Krijger
Microsoft Corporation


Due to an initial lack of formal standards and subsequent adherence to that non-standard behavior, many Web sites have been designed and built to serve multiple client browsers. It is common to see name- and version-specific checks that are hard-coded into HTML to provide the best shared Web browsing experience to diverse audiences and their requirements. Browser targeting, cross-compatibility, and development of multiple Web sites in parallel have been painstaking endeavors for Web developers. With Internet Explorer 8, we have aimed to reduce the amount of time and effort required by these tasks, as well as to improve the support for true cross-platform standards compliance and browser compatibility.

If best practices are followed in development, the default appearance and behavior of a Web site viewed in Internet Explorer 8 should be the same as in Internet Explorer 7. By default, however, Internet Explorer 8 uses a more compliant Standards mode that supports the latest feature set in the CSS 2.1 specification. Development under this mechanism produces a unified code base whose benefits include better compliance with standards, a single shared browsing experience, and a faster and simpler development process. Internet Explorer 8 also provides a mechanism for emulating the strict mode behavior of Internet Explorer 7.

In this document, we provide a brief overview of the changes that are built into Internet Explorer 8 and are most relevant to Web site testing. In addition, we relate these changes to existing real-world problems, demonstrate best approaches for debugging code and reducing problem Web pages, and give guidelines for testing Internet Explorer 8 Standards mode.


The Developer's Cheat Sheet
Do You Recognize This Code?
Take a Deeper Look

The Developer's Cheat Sheet

This section describes the features of Internet Explorer 8 that are most relevant to Web site testing and compatibility, specifically:

  • Configurable document mode: Quirks, Internet Explorer 7 Standards, and Internet Explorer 8 Standards
  • Powerful debugging tools for HTML, CSS, and script
  • Ability to use the opt-in for Internet Explorer 8 mode to code for different audiences
  • Ability to choose between the default Internet Explorer 8 mode and Internet Explorer 7 Compatibility View

The current document mode can be changed using the Internet Explorer 8 Developer Tools. To open the toolbar, press F12 and use the Document Mode drop-down list box to switch between modes. This is an easy way to test whether your Web site will display correctly under different versions of the browser. For Web sites that have previously rendered in Internet Explorer 7 Standards mode, the default mode is Internet Explorer 8 Standards. To clarify how the Web page is interpreted, the Web page default is also displayed in the drop-down list box. If coded correctly, existing Web sites will render exactly as they do in Internet Explorer 7.

By providing visibility into Internet Explorer’s internal representation of a Web site, rather than just a source view, Developer Tools can help you identify why a Web site does not render or behave as expected. In the HTML pane, navigating and inspecting the DOM tree becomes a simple task, while CSS and script can be examined separately. One powerful feature of the script view is to enable developers to insert breakpoints, step through code, and watch variables, locals, and the call stack.

Despite a significant effort to keep Internet Explorer 8 backwards-compatible, certain development practices examine the user-agent string. For this reason, to achieve the most compatible browsing experience, Internet Explorer 8 enables you to report the Internet Explorer 7 user-agent string. To do this, use the Internet Explorer 7 Standards mode, and emulate Internet Explorer 7 at the same time, switch Compatibility View on using the toolbar button or menu option.

Compatability View

Example Internet Explorer 8 User-Agent string:

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 1.1.4322)

Example Internet Explorer 7 User-Agent string:

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 1.1.4322)

The default mode is Internet Explorer 8 Standards, which takes advantage of enhanced support for the CSS 2.1 specification. To remain in Internet Explorer 7 Standards mode by default, insert the following tag into the head element of the Web page:

 <meta http-equiv="X-UA-Compatible" content="IE=7" />

Do You Recognize This Code?

Some of the common practices for developing against multiple browsers are listed below.

<script type = "text/javascript">
function detectBrowser()
  var browser = navigator.appName;
  var b_version = navigator.appVersion;
  var version = parseFloat(b_version);
  if ((browser == "Netscape" || browser == "Microsoft Internet Explorer") && (version >= 5))
    alert("Your browser is good enough!");
    alert("It's time to upgrade your browser!");

This example is fairly innocuous; however, slight variations could be much more troublesome:

if (version >= 5 && version <= 7)
   alert("Your browser passes the test");
   alert("Your browser fails, because I forgot about Internet Explorer 8.");

if (is_nav4 || is_ie6) { /* Nothing other than these works */ }
if (ie_version == 7) { /* Only Internet Explorer 7 works */ }

The following CSS workaround example provides two different spacing values: one to Internet Explorer and the other to any other browser.

#header {margin-bottom: 3em;}
html>body #header {margin-bottom: 1em;}

Web sites often use these objects incorrectly to test for specific browsers:

window.Iterator                         Detects Firefox 2 and later.
document.compatMode && document.all     Detects Internet Explorer 6 and later.
window.XMLHttpRequest                   Detects Internet Explorer 7, Firefox1+, and Opera 8 and later.

Take a Deeper Look

IE8 Developer Tools

After you follow best practices and avoid the minor problems described in the previous section, it is possible that under Internet Explorer 8 your Web site will not behave as expected. Alternatively, the initial steps taken to improve the Internet Explorer 8 experience might break backwards compatibility. This section outlines some general debugging and troubleshooting, with focus on Internet Explorer 8.

User-Agent String

Switching the user-agent string and document handling back to the Internet Explorer 7 mode is a quick and easy litmus test and the first step towards understanding a problem. Although we have spent substantial time and effort to keep Internet Explorer 8 backwards-compatible, we expect that some Web sites will not be prepared for the browser's new user-agent string. However, we anticipate that simple problems will be resolved using this test, and that information the test provides will be communicated to Web site owners to further rectify a problem.

The Developer Tools

For a detailed guide on the Developer Tools, refer to Developer Tools Hands-On-Lab; the basic ideas will be repeated here. For problems that require a deeper investigation—specifically, DOM, CSS, and scripting—the Developer Tools offer Web developers and enthusiasts an accessible and functional methodology. The Developer Tools ship with Internet Explorer 8 and can be accessed through the toolbar or by pressing F12. To allow rapid debugging and investigation, we have implemented three tab panels corresponding to the three aforementioned areas. As a starting point for gaining familiarity with the Developer Tools, refer to the following two key methods.

Open Internet Explorer, navigate to any Web site and open Developer Tools. Click the Select Element by Click icon in the toolbar, and then click any element on the Web site. This will immediately display all of the element's attributes and its position in the DOM hierarchy. This is an extremely efficient method for isolating specific nodes on a complex Web page, especially one that is built dynamically. Navigate to a Web page that has a scripted functionality, and click the Script tab. To enable script debugging in Internet Explorer, use the Advanced Options menu, or simply click Start Debugging. Now you can insert breakpoints by clicking to the left of the line number or by pressing F9. Activating a script through the Web page will present you with a break in the script, making available the variables, call stack, and other debugging information.

As mentioned in the previous section, this method is a simple way of debugging a particular class of problems that will arise if the browser identity is tested using objects. Due to standards compliance changes, some of these objects will now change their behavior and evaluate to NULL, thus breaking the existing code because it did not follow best practice guidelines. If new script errors are the problem, stepping through the script code is an appropriate step to start the investigation.


For issues classified as changes in requests, responses, headers, status codes, character sets, and related data that is handled before any bits are passed to the browser, Fiddler is an excellent tool. Used primarily for examining and manipulating requests before they are made or for responses before they are passed back, Fiddler can also trace the flow and redirection of network traffic—such as Connect and Post methods and WebService requests—which is difficult to debug any other way.


Step 1. Investigate the document mode

  1. Have you made registry changes at any point?
  2. Is Compatibility View enabled? Check the toolbar button, menu option, and domain list.
  3. Is there a meta tag that specifies the version?
  4. What mode does the DDT put the browser into?
  5. Using the Developer Tools, check or set the browser mode and document mode.
  6. Run javascript:alert(document.documentMode) using the script or the Address bar.
  7. Try placing the mouse pointer over some selectable text. If the cursor does not change from the pointer to selection, the Web page is running in Internet Explorer 8 Standards mode.
  8. Navigate to a marquee test page; marquees have not yet been implemented in Internet Explorer 8.

Step 2. Save the Web page locally

This is a very important step, because Web pages change all the time. This process used to be more challenging; however, the Save As functionality has been greatly improved.

  1. Save the Web page locally and name it after the domain, for example meyerweb.htm. If no error messages are generated during saving, you can proceed.
  2. The folder that was saved along with the .htm file contains the resource files, including .css, .js, and .jpg.
  3. The .htm file is connected to the resource files; if you delete it, the resource folder will be deleted as well.
  4. If you use Webpage, HTML only, the relative paths such as src=./support/example.css will not get fixed.

Step 3. Reproduce the problem

Example code showing Relative and Local paths
  1. The first step in reducing severity of the problem is to verify the original reproduction with your local content.
  2. If your local Web page reproduces the problem immediately, you are in good shape.
  3. If the Web page does not reproduce, first find and fix external resource paths until the problem comes back; in this example, you would replace the relative path, ../../search/search.xml, with the complete path,
  4. Fix one line at a time, and then do a refresh. If you lose the problem at any time during this process, simply press CTRL+Z to undo the last deletion.
  5. As soon as you can reproduce the problem, continue.

Step 4. Remove the big stuff

  1. Clean out the header section first; this is usually where most of the external references are located.
  2. Remove all script blocks, meta tags, the title, and anything else that is not essential for Web page layout.
  3. Remove as many style sheet references as you can, leaving only those that are required.
  4. Refresh (or press F5) and verify that the problem can still be reproduced.
  5. Search through the remainder of the document for script and style blocks. Remove each block and verify that the problem is still present.
Developer Tools in action

Step 5. Take aim with the Developer Tools

This step enables you to see a lot of information about the problem, including where it is in the DOM tree. Start at the topmost parent node that contains the problem, in this case the element with the id: "extra"; anything outside of this node is usually not related to the problem. You can delete the element id:“main” and everything above it, and id:“pointers” and everything below it.

Example reduced code

The Web page has been reduced as much as possible: by removing code one line at a time, then styles, IDs, and classes—until nothing could be removed without losing the problem.

Step 6. Reduce the Style Sheet

The next step is to reduce the CSS file. Open the file in an editor and copy all the styles into a <STYLE> block in the local file; in most cases, this will be a large list of styles. If there is more than one .css file, repeat this process, making sure to delete the link that references the .css file. Now, begin the binary search-and-replace until you reduce style block to just a few styles needed for reproduction. When there is only one style block left, remove styles one by one. Next, check whether you can remove any more elements, class names, or IDs.

Example reduced code (minus Style Sheet info)

The final result is a single html file containing only 22 lines of code that you can use to easily demonstrate, test, and target this specific problem.

Screen capture of a rendering problem.

Hans Krijger is an SDE/T on the Internet Explorer team. He runs site compatibility, and contrary to popular belief he sleeps several hours a week.