Web developers who are using IE9 might have already played with the new F12 developer tools and have seen "Browser mode" and "Document mode". For those of you who haven't explored, the are the menu options which you can find in the developer tools of IE8/IE9 (hit F12 key and check). These are basically useful to test and make sure that your site runs well in various versions of IE.
Web developers use browser and document modes frequently, yet not many know how these two differ and when to use what. e.g., If you are using ECMAScript 5 object model (which is supported in IE9) and want to have fallback options in lower versions, what would you use to test? Browser mode or Document mode? In the first place, why should there be two such options in the F12 tools and how did they evolve?
This post tries to answer the above questions and help web devs ease their exploration. Before looking at when to use these options, let us dig back into the sweet history and see how these modes evolved. I'm sure this would make the modern day (drag/drop day?) web developers understand their responsibility in building a web of standards!
Doctype, Quirks mode, Standard mode:
The entire concept of different browsing modes originated in March 2000, when Internet Explorer-5 (IE5) for Mac was released. It was supposedly the most standard compliant browser at that time (better than IE5 for Windows). It was following standards so seriously that all the legacy, handcoded webpages of that time broke. Microsoft innovatively solved this issue by looking at "Doctype". Pages which had a valid doctype directive were rendered as per latest web standards by browsers (Standard Mode). Else, they were rendered as per the quirks/vendor specific implementations of late 90s (Qurik's Mode). This idea was implemented by most of the major browsers and it existed till date. Hence evolved the "Standards Mode" and "Quirks Mode".
e.g., This is how XHTML1.0 Doctype looked like:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
W3c has a very useful page on why you should follow web standards (make sure your manager reads this!)
With HTML5, the Doctype got over simplified!: <!DOCTYPE html>
The Doctype tells the browser about the version of markup used and instructs it what rules it should follow to render the content (e.g., ignoring deprecated tags, allow/disallow framesets etc).
So, the issue of distinguishing pages which follow standards from those which do not follow got resolved. However, browser specific quirks still existed, which would create a bigger problem.
User-agent string and Browser detection:
While some of the websites designed in early 2000 slowly adapted to doctype and standards mode, a majority of them targeted proprietary features and maintained different pages for IE and Netscape, for the same site. This is done using a technique called Browser Detection. As the name suggests, a web server can detect the browser used to send a HTTP request. This info is sniffed from a string in the HTTP header of a HTTP request, called the User-Agent.
E.g., The user-agent string for IE8 looks like:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)
and the user agent for Firefox 5.0 looks like:
Mozilla/5.0 (Windows NT 6.1.1; rv:5.0) Gecko/20100101 Firefox/5.0
Since the user-agent string is sent in HTTP request, it can be queried on the server, e.g., in ASP.NET using C#, as:
String userAgent;
userAgent = Request.UserAgent;
if (userAgent.IndexOf("MSIE 6.0") > -1)
{
// This browser is IE 6.0.
}
Even today, many websites use browser detection via user-agent not only for browser compatibility, but also for other reasons like preventing web crawlers from making expensive database calls, denying permission to very old browsers for security/business reasons etc.
Browser detection via user-agent string helped in distinguishing different browsers and handling their quirks. However, developers don't yet have a chance of saying that they are not ready to migrate to a newer version, or they want to target only a specific version of IE till they migrate.
Document Compatibility:
On one hand, while web developers followed web standards/browser specific tweaks, new versions of IE came in, fixing lot of existing bugs, introducing newer features and supporting several W3C standards. IE6 did not support the universal selector ('*'), while IE7 added this support. The standards mode of IE7 replaced the standards mode of IE6, which forced developers to migrate their sites to IE7 standards mode. This became a problem, since there is no way of targeting a specific version of IE, as they are unsure if a better standard in a newer version of browser might break their code.
When IE8 was released, it introduced the concept of document compatibility, which provides an option to developer to specify the version of IE that they intended to support. Taking into consideration the large userbase of IE and millions of web pages which already existed with version specific tweaks, this was a welcome change. Developers can specify the version they want to target via an X-UA-Compatible header in meta tag, like:
<head>
<!-- Respects Doctype directive and renders in Internet Explorer 8 standards mode-->
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" >
<title>My webpage</title>
</head>
In JavaScript, the document mode can be found using: alert(document.documentMode);
The whole idea of compatibility mode is NOT to ask developers to target specific version. Instead, it is in support of "Don't break the web" clause. This way, developers can take time to follow proper web standards (without depending on version specific quirks) and migrate to latest browsers, without breaking their site.
How F12 Developer tools help:
Having understood the background so far, it is obvious that developers/businesses have a tough time in supporting rapidly evolving standards, meet the quirks of existing browsers without compromising on business functionality.
Browser mode: To test for different versions of IE, the "Browser mode" option in F12 tools can be used. It sets the user-agent string to the browser mode option which is chosen and sends HTTP request to the server (this is a full postback). The site then responds with an appropriate document type, based on the doctype and X-UA-Compatible header.
So, if you select IE8 browser mode, IE will present the page in a way which IE8 user experiences. Also, since the user-string is sent in HTTP request to the server, the browser detection code written in C# (as seen in the above section) works and all server side manipulations can be done.
Document mode: The document mode essentially decides the mode in which IE's rendering engine (Trident) should display the markup. In other words, changing the document mode in F12 tools will have exactly the same effect as specifying your own X-UA-Compatible header in your web page. The main difference from browser mode is, when document mode is changed, there will NOT be a fresh request to the server and hence the user-agent string will NOT be sent. Its only that the rendering engine displays content according to your choice.
Bonus: The F12 tools also provide an option to test your site in different browsers. Harish Ranganathan wrote a recent blog post on changing user agents.
Few tips:
(1) Use <!DOCTYPE html> directive as a standard for your web pages. It is backward compatible and also makes your site HTML5 enabled.
(2) Do not use browser detection. Use feature detection instead.
(3) Use X-UA-Compatible header only till you make your site standards compliant. Get rid of it at the earliest so that your site can scale along with modern standards/browsers.
(4) Use libraries like Modernizr for feature detection, instead of borrowing buggy JS code from the internet.
References worth reading:
(1) Why IE5/Mac matters-AlistApart
(2) IE8 Document & Browser mode-Nicholas Zakas
(3) Testing sites with Browser mode vs Document mode-IE Blog
(4) Understanding User-Agents-IE Blog