We have talked about our goal with IE9 to run the same standards-based markup as other browsers by default. It is also our goal for IE9 to successfully run the Web that you browse today. For sites that are designed to run in older versions of IE, IE9 includes support for compatible document modes and a Compatibility View (CV) List that’s similar to what shipped with IE8.
The CV List and compatible document modes are good for site developers because they enable developers to transition between IE8 and IE9 on their own schedule. We only add a site to the CV List when the site is designed to run in an older version of IE, doesn’t run well in IE9’s Standards mode, and doesn’t declare an X-UA-Compatible meta tag or header. The CV List is good for users because it means that IE9 works great with popular sites the day they upgrade and without users having to click on the Compat View button.
We want the CV List to be as small as possible when IE9 ships and to get smaller over time because more and more of the web works well in IE9 by default. This is good for users and site developers. To achieve this, we want sites to update now to work well in IE9’s Standards mode and serve the same markup they use with other browsers. At a minimum, sites should take advantage of the IE7 or IE8 document mode by declaring an X-UA-Compatible value until they can update.
The IE9 Beta CV List currently has just over one thousand sites listed. This is a third of the size of IE8’s CV List, which originally shipped with 3122 sites listed.
The IE9 CV List is capable of customizing how each website runs. We want as many sites as possible to render in IE9’s Standards mode so that they can take advantage of HTML5 capabilities and performance improvements. Today many sites use browser detection instead of feature and behavior detection to give IE different markup that is not interoperable with IE9’s Standards mode or other browsers. This can result in major functionality breaks on sites rendered in IE9’s Standards mode.
For example, IE9’s Standards mode strictly follows the createElement() DOM standard to be interoperable with other browsers. A simple test for this behavior is even part of Test 22 of Acid 3, which checks that browsers throw an INVALID_CHARACTER_ERR exception when a webpage tries to pass invalid characters into createElement().
function () {
// test 22: createElement() with invalid tag names
var test = function (name) {
var result;
try {
var div = document.createElement(name);
} catch (e) {
result = e;
}
assert(result, "no exception for createElement('" + name + "')");
assertEquals(result.code, 5, "wrong exception for createElement('" + name + "')"); // INVALID_CHARACTER_ERR
}
test('<div>');
test('0div');
test('di v');
test('di<v');
test('-div');
test('.div');
return 2;
}


Passing this Acid3 test and being interoperable unfortunately leads to breaking sites with IE-specific code in IE9’s Standards mode. For example, the page header and menus aren’t displayed on verizonwireless.com in IE9’s Standards mode because it relies on IE8’s more lenient behavior for createElement(), which accepts valid HTML in addition to specific element names.

To keep sites working well in IE9’s Standards mode instead of reverting to IE8 or IE7 Document modes, the IE9 CV List includes a new capability called a “featureSwitch.” This makes specific APIs in IE9’s Standards mode behave as they do in previous IE versions.

For example, the IE9 CV List has a “featureSwitch” called “createElementWithMarkup.” This re-enables IE8’s more lenient behavior for createElement() in IE9’s Standards mode, but only for specific sites on the CV List.

<domain docMode="EmulateIE9" featureSwitch="createElementWithMarkup">verizonwireless.com</domain>

We intend to remove feature switches as soon as sites update themselves to use the same markup across browsers. We reserve feature switches for specific, high-impact changes that we’ve found through testing to affect many web sites. We won’t create feature switches for every change in behavior and sites cannot opt-in to them. Instead, sites should opt-in to the IE7 or IE8 Document Mode through the X-UA-Compatible meta tag or header to get compatible until they can update to IE9’s Standards mode.

Sometimes Conditional Comments are used to make webpages work in IE6 and IE7. In IE9’s Standards mode, a site doesn’t need them. The IE9 CV List can make Conditional Comments targeted at old versions of IE work in IE9 Mode or turn them off for a site. This is a temporary solution until the site developer has a chance to make updates to stop using them in IE9’s Standards mode. In addition to featureSwitches and the ability to turn off Conditional Comments, the IE9 CV List can put sites in Compat View, just like the IE8 CV List did. The IE9 CV List can also change the Document Mode that a site renders in to IE7 or IE8.

We’ve updated how we populate the CV List to avoid putting websites on it that don’t need it.

Different from IE8, before adding a site to the IE9 CV List we verify that it is incompatible with IE9. We also verify what Document Mode it works best in. This will help us make sure that we ship with the smallest CV List possible at Beta, RC and RTM.

The CV List continues to be community-data-driven. For the IE9 Beta CV List, we use data from site compat testing and internal usage to determine what sites go on the list. For the RC and RTM CV Lists, we’ll rely more on data from Beta and RC selfhosters.



The IE9 CV List is quickly and simply deployed as a webpage.

We just shipped a CV List update to IE9 Beta and it only took a few minutes to ship. We added sites including ted.com, mkb.hu, and hoyts.com.au based on IE9 Beta customer response. The IE9 CV List is an XML file on Microsoft.com. We can update the list daily through this mechanism, which means we can quickly accommodate site developer requests to remove updated sites.

Another benefit of deploying the CV List as a webpage is that users automatically get updates instead of having to download the optional IE8 CV List packages from Windows Update or Download Center (users can opt-out just as easily as IE8 too).

You will be able to view the IE9 Beta CV List on your local machine by navigating to this file path:

File:\\%LOCALAPPDATA%\Microsoft\Internet Explorer\IECompatData\iecompatdata.xml

The server version, which is used to ship updates to IE9 is located here.

Ask to site developers

While verifying that your site works well in IE9 Beta, please check to see if it is on the IE9 Beta CV List here. If it is on the list, uncheck “Include updated website lists from Microsoft” in the Compatibility View Settings (Alt –> Tools --> Compatibility View Settings).



Use IE9’s improved Developer Tools to resolve compatibility issues. Lastly, please email iepo@microsoft.com with the information at the bottom of this webpage and ask to be removed from the IE9 CV List when your updates are live on the web. This will help make sure users have an amazing experience when they install IE9 and browse to your site.

Thanks,
Marc Silbey

Program Manager

This post introduces IE9’s User-Agent (UA) String and it builds on previous blog posts and documentation.

An important change for site developers to know is that IE9 will send the short UA string by default. This change improves overall performance, interoperability and compatibility. IE9 will no longer send additions to the UA string made by other software installed on the machine such as .NET and many others.

Some folks will notice that the IE9 Platform Preview sends IE8’s UA string. We will include the new IE9 UA string in an upcoming Platform Preview update. The reason we’re writing about IE9’s UA string now is to give site developers an early preview of these important changes and time to verify that any current UA logic continues to work with the new IE9 UA string.

IE9’s default UA string

There are four changes to IE8’s UA string that site developers need to be aware of:

Application version is incremented from ‘Mozilla/4.0’ to ‘Mozilla/5.0’ to match other browsers (explained well in the great History of the user-agent string post). This change signals that IE9 is an interoperable browser.
Version token is incremented from ‘MSIE 8.0’ to ‘MSIE 9.0’.
Trident token is incremented from ‘Trident/4.0’ to ‘Trident/5.0’.
IE9 will send the following short UA string without additions made by other software installed on the machine:
IE9 will send the short UA string by default

We’ve received many reports  on compatibility issues due to long, extended UA strings. IE9 will send the short UA string detailed above without pre and post platform registry value tokens. This is interoperable with other browsers, and improves compatibility and network performance.

Applications and platforms can continue to add to the UA string through the pre platform and post platform registry keys as they did in previous IE releases. IE9 will not change existing registry values.

Websites will continue to be able to get the extended UA string with pre and post platform tokens through the navigator.userAgent property.

IE9’s Compatibility View UA string

Similar to IE8, IE9’s Compatibility View will map to IE7 Standards Mode, and IE9’s UA string when in Compatibility View will be:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/5.0)

In Compatibility View, IE9 reports itself as IE7 through the application version number (Mozilla/4.0) and version token (MSIE 7.0). This is done for compatibility. An incremented Trident token, from ‘Trident/4.0’ to ‘Trident/5.0’, allows websites to distinguish between IE9 running in Compat View and IE8 running in Compat View.

Request for site developers

Test how your site responds to the new IE9 UA string (check and change the UA string through the registry). If your site doesn’t already respond with IE-compatible content, we’d love to see it updated now to recognize IE9 and be future-proof.

Marc Silbey Program Manager