It’s For-IE-day: Week 3

Last week we took a look at Compatibility View as a way to retain the older rendering functionality just in case your site wasn’t working quite right (yet!) with IE8.  Today, we’ll look at a related aspect, namely how you as web developers can detect that a client is using IE8 and respond accordingly.

Before I get started though, if you haven’t yet installed IE8, you can proactively do so at any time, but you will also start seeing IE8 being pushed down as an optional install via Windows Update (if you haven’t already).  This blog post from the IE team provides a bit more detail into the roll-out plan.

Now on with our program!  Last time I showed you how the IE Developer Tools, another cool new feature of IE8, can come in handy to determine how IE will behave based on a page’s <!DOCTYPE> and X-UA-Compatible header. Along side the resulting “Document Mode” is displayed a “Browser Mode”, with the three options you see here:

Modifying the Browser Mode affects how Internet Explorer describes itself to the targeted web server.  In contrast, Document Mode describes the rendering mode that the page requests of Internet Explorer.  In terms of Browser Mode, there are three bits of information that IE reports and three modes that it may report them in.   The specific bits of information are the

• User Agent String,
• Version Vector, and
• Document Mode

By setting the Browser Mode to one of the three options (described below), you’re affecting how IE reports those three bits of information to the server.  So, as a result you can use Browser Mode to force IE8 to behave in three different ways, and so gauge the variety of experiences that your end-users will have.  Specifically, a Browser Mode of

• Internet Explorer 7 causes IE8 to present itself to sites as if it were IE7, and so you can use this mode to test how a site would display with IE7 installed.  This is especially valuable since you can’t install both IE7 and IE8 on the same machine.
• Internet Explorer 8 causes IE8 to present itself as, well, IE8
• Internet Explorer 8 Compatibility View provides the experience a user will have if they are viewing he site in Compatibility View (e.g., they pressed the ‘broken link’ button near the URL textbox or the site is on a list of sites then display in compatibility view automatically – sites you’ve added explicitly or sites on the Microsoft-maintained list). While IE 8 Compatibility View strives to provide an IE7-like experience, there are differences to be aware of.

Next, let’s look deeper at what those three pieces of information presented by the browser are and how modifying the Browser Mode affects them.

User Agent String

A User-Agent string is a piece of information presented to a web server to help identify the client application, in our case, the IE browser version.  There are a number of different ways to ‘catch’ the user-agent string; the Fiddler web debugging proxy, for instance, will do this and a ton more.   There’s also a few pubilc sites out there that will just echo your user-agent string to you; the aptly named https://www.useragentstring.com is one.  And, you can just simply type

as a target location in your browser to get the string reported to you in a message box.

Here is the string I get from my IE8 installation

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; OfficeLiveConnector.1.3; MS-RTC LM 8)

There’s obviously quite a bit of information tacked on to these strings.  For instance, you can see I’m running 64-bit Vista (“NT 6.0”); what other items are there will depend on other software you’ve got installed on your machine.  While it’s a noble goal to want to understand each and every nuance of a user-agent string, it’s a bit beyond the scope of a single blog post, and when you consider that one public source (https://agentdb.com) has catalogued over 86,000 user agent variations, the task is a bit daunting.  Here we’ll focus only on the salient aspects that help differentiate IE7 and IE8 modes.

First, let me list four different user-agent strings; three reflect the various Browser Modes exposed in the IE Developer Tools and the other is from an IE7 installation on a separate machine.  The underlined sections are the areas we’ll focus on.

IE8

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; OfficeLiveConnector.1.3; MS-RTC LM 8)

IE7 Browser Mode on IE8

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; OfficeLiveConnector.1.3; MS-RTC LM 8)

IE7 (using IE7 on a second machine)

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; InfoPath.2; MS-RTC LM 8; .NET CLR 3.5.21022; Zune 3.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618)

IE8 Compatibility View

Mozilla/4.0 (compatible; MSIE 7.0 ; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; OfficeLiveConnector.1.3; MS-RTC LM 8)

One option to detect the various manifestations of IE is to parse the user agent header in your client or server-side script.   MSIE 8.0 clearly represents IE8 in its native mode.  MSIE 7.0 though could actually represent IE7 or IE8 masquerading as IE7.  In fact, IE itself masquerades as Mozilla already!  To detect whether a client is actually running IE7 versus IE8 in Compatibility View, you can rely on the presence (or absence) of the Trident/4.0 token (Trident refers to the layout engine for IE).

While this technique will detect most versions of IE, be aware of the advice in one MSDN article that

…the user-agent string is dynamic; it can be changed by the end user, by browser extensions, and by operating system updates. As a result, there's no guarantee that the user-agent string accurately reflects the browser being used.

If you opt for ‘user-agent sniffing’, as it’s called, here’s some resources to help, whether you are detecting the browser type in your server-side or client-side script:

How To Determine Browser Version from a Script

HOW-TO: Determine the Browser Version in ASP.NET

How To Determine Browser Type in Server-Side Script Without the BrowserType Object

Version Vector

IE5 introduced the concept of conditional comments, essentially including content to be delivered into a comment block.  The content is preceded by a conditional statement that detects the browser version.  The version number included in these conditional statements is referred to as the version vector, which can be a major release number like 8, or a minor release, like 5.5.  In practice, the version vector is commonly used to deliver CSS targeting specific IE versions (something that should become less frequent given IE8’s embracing of the CSS 2.1 specification!).

Here’s a quick example, a simple page with some conditional comments to display various text depending upon the browser version.  As you can see there are a number of logical operators supported, including lt (less-than), lte (less-than or equal to), gt (greater-than), gte (greater-than or equal to), ! (not), & (logical AND), and | (logical OR).  Here’s a sample script, and with the Browser Mode option in IE8’s Developer Tools, we can explore how the page will be interpreted with the various different options below.

 <HTML>
<BODY>

<!--[if IE 7]>
<p>Welcome to Internet Explorer 7.</p>
<![endif]-->

<!--[if IE 8]>
<p>Welcome to Internet Explorer 8.</p>
<![endif]-->

<!--[if gte IE 7]>
<p>Welcome to Internet Explorer 7 or higher.</p>
<![endif]-->


</BODY>
</HTML>

Browser Mode: Internet Explorer 8

Browser Mode: Internet Explorer 7 (and IE7 on second machine)

Browser Mode: Internet Explorer 8 Compatibility View

Of course, this conditional comment feature will work only with Internet Explorer; Firefox for instance, will provide the rather sparse display to the right when browsing to that same page.  The conditional compilation approach, however, does not add additional overhead in this case, since Firefox simply skips over that content as a being just a comment.  And even in IE, there’s a bit of an advantage in both performance and developer effort, since conditional comments don’t require any scripting or user-agent sniffing.

In case you’re wondering, the version vector is stored in the HKEY_LOCAL_MACHINE hive of the registry, as you can see from the Registry Editor screen shot below.

.

Document Mode

The last bit of information associated with the Browser Mode is Document Mode, the same topic we discussed last week.  Modifying the Browser Mode may also cause the default document mode to be changed . 

For instance, changing Browser Mode to IE7 or IE8 Compatibility View will trigger a Document Mode of “IE7 Standards” (or “Quirks Mode” if there is no standards-based <!DOCTYPE> tag), and changing Browser Mode to IE8 will trigger “IE8 Standards” (or “Quirks Mode”).

Of course, you can set Document Mode independently as well after setting Browser Mode to see the effect of the various rendering options on your page.  Remember though, setting Document Mode does not effect how the browser identifies itself; that’s where Browser Mode (and the user-agent string and version vector) come in.

Additional Resources

The Internet Explorer 8 User-Agent String

Detecting Internet Explorer More Effectively

Testing Browser and Document Compatibility Modes with the Developer Tools

UAPick Utility (to spoof other user-agent strings in IE)

Next week we’ll take a looks at the enhancements in search capabilities and how to hook-in your own search provider.