This post describes how IE8 determines what Document Mode such as Quirks or Standards Modes to use for rendering websites. This topic is important for site developers and consumers.
It’s related to the Compatibility View List that we recently updated. This list is down by over 1000 websites, from over 3100 to just over 2000, since IE8 released last March. As we work with site developers and standards bodies, we’re excited to see the sites that need to be on the Compatibility View (CV) List continue to go down.
Data-driven Design
Before we dig in to the design details, I want to share some of the data we use to design the compatibility experience.
When looking at the doctype and X-UA-Compatible meta tag and header on thousands of high traffic websites worldwide such as qq.com, netlog.com and those on the initial CV List,
Here’s why this makes sense; many high traffic websites want to render in as many browsers as possible, which is why they write for Quirks. Many websites have pages written specifically for IE7 and many web authoring tools such as Aptana Studio and Expression Web specify the Transitional doctype by default:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Thinking in terms of web-scale, there are billions of pages written specifically for either Quirks, IE7, Almost Standards, or the latest Standards. IE needs to support all of these web platform variations to ensure that our broad, world-wide, user-base has the best experience.
With this data in hand, we designed IE8 with a few principles in mind:
As stated in previous posts, we’re committed to interoperability, which means rendering websites in the most standards compliant way possible by default.
A small set of users will tinker to get websites that expect and work best in IE7 Standards Mode to work in IE8’s more standards-compliant default mode. For everyone else, IE8 includes Compatibility View Settings.
The best experience here is one that works automatically as the web developer intended. This is why we created the Compatibility View List. It’s also important to give users the ability to fix websites that aren’t on the list yet through the Compatibility View button.
The X-UA-Compatible meta tag and header override IE and user settings. They also provide web developers with fine-grain control over how each webpage renders in IE.
For example, some websites have pages written for Quirks and others for IE7 Standards. When IE receives an X-UA-Compatible header with an EmulateIE7 value from servers, it renders each page in the appropriate Quirks or IE7 Standards Mode.
IE8 introduced the X-UA-Compatible meta tag and header to provide web developers time to transition their websites to IE8 Standards. As mentioned above, many websites have already used this mechanism to specify that their content should run in IE7 Standards Mode.
A Diagram on How IE8 Determines Document Mode
Given the above principles, there are four rules that you can remember about how IE handles doctype, X-UA-Compatible meta tag and header, Developer Tools, and Compatibility View Settings. These rules follow the diagram below from top to bottom:
Compatibility and interoperability are complex. To reduce complexity for developers and users alike, we would love to see websites transition from legacy browser modes. We respect that the choice of mode is up to the site developer. We’re excited to work with sites and standards bodies to continue improving IE’s implementation of interoperable standards.
Many thanks to Jesse Mohrland for verifying the diagram.
Marc Silbey Program Manager
I appreciate the explanation though my interest is with XHTML. While IE does not yet support application/xhtml+xml is does support application/xml. Unfortunately IE sends a request for the doctype and since the W3C sniffs for the IE user agent, it's not found, then IE automatically throws itself in to quirks mode. To get around this I have to use HTML5's not-a-doctype-doctype (lacking version numbers make it incredibly not-forward compatible). Furthermore to get IE8 to render the page instead of displaying the XML source <?xml-stylesheet has to be used after the XML declaration. To handle backwards compatibility I first use JavaScript to check the DOM/Conditional comments to determine the browser and version, AJAX the result, and store the information in the user's session.
I would greatly appreciate it if sometime in the reasonably near future if you folks could blog about getting XML to work exactly how you've explained the various rendering modes. I've seen plenty of examples one in particular where a guy blew an entire day checking serverside code and everything because one browser wasn't rendering as desired though the rest were and he was simply missing a quote. Had he used XHTML the entire page would have broken (Gecko and Presto do this correctly, IE does this correctly with application/xml, and KHTML and WebKit fail to display an error) and the error that needed to be fixed would be VERY apparent thus requiring minimal effort to fix. XHTML is also extensible so in example when the W3C removed the target attribute from anchors and the border attribute from the frameset element leaving web designers (and web developers outsourced to do web design) with XHTML one can re-extend support and still have pages validate.
It's going to be VERY interesting to see how this topic evolves in IE when IE9 is finally made available to the public and I am very enthusiastic about spending time with IE9 much the same way I did with the first build of Opera 10.5!
Nice chart, but what about unknown doctypes like the HTML5 doctype?
Also: Why are the JPEG compression artefacts in a PNG image?
@'John A. Bilicki III': Well, the doctype was originally not intended for versioning. That was AFAIK also the rationale behind defining the HTML5 doctype this way.
And IMHO handling backwards compatibility with Javascript is a very bad idea.
@George Wurst
Before JavaScript with DOM (not user agent) sniffing in IE6 rendered in stadards mode...
http://img25.imageshack.us/img25/8097/ie6standardsjs0.png
After JavaScript DOM sniffing in IE6 rendered in stadards mode...
http://img442.imageshack.us/img442/1193/ie6standardsjs1.png
If you know how to work with the DOM you can patch any browser by creating a new link element and loading the correct browser/version related style sheet. This can be done with 100% accuracy without the need for conditional comments. In the 29th version of my site I'm also doing this to load CSS3 stylesheets so that not a single browser has console errors while every browser that supports CSS (be it by standard or proprietary implementation) is supported...again without any console errors at the highest sensitivity to errors.
X-UA-Compatible?? Why not ;)
<meta http-equiv="X-UA-Compatible" content="chrome=1">
@John: I don't mean to troll or anything, but your site looks horrible. And the fact it's the 29th version makes me an even sadder panda. :(
You may know the "web" part of "web design", but now it's time to spend more time on the second word.
Disclaimer: I know my site design also sucks, so no need to point that out. It's not the 29th version though, more like the 4th.
@IE team, don't suppose there is a way to force IE7 to render application/xml in standards mode or is that exclusively for IE8?
@Stifu People are quick to make statements and most make absolutely no effort to make inquiries. First off I don't care if someone likes my *personal* website. Secondly it supports themes. Thirdly the current theme is not finished so it would be pointless for me to start making a second theme now when I still anticipate making changes to the existing theme since I haven't finished porting/adding content. Fourthly: http://www.jabcreations.com/blog/?prompt=themes-editor
...and fifthly which would you fix first? An HTML error that breaks the page for people in 30% of the browser market or a style preference? Sometimes the person behind the wheel really does know where they are going...it happens more often then people think. ;-)
"It's not what you look at that matters, it's what you see." - Henry David Thoreau
Aptana Studio does not create a transitional doctype for an empty HTML document. It uses strict.
Just a hint:
If you want to use X-UA-Compatible in a valid html5 document, just use this snipplet:
<code>
<!--[if IE]>
<meta http-equiv="X-UA-Compatible" content="chrome=1" />
<![endif]-->
</code>
The validator will not interpret it and real browsers don't need it.
The part I love most about this post, is that it was released ONE FULL YEAR after the browser shipped!
Not having this as a reference is one of the reasons that developers were despising IE, trying to get their sites to render properly in IE6, IE7 and IE8.
Developers install IE8 and test in it and pseudo-IE7 but then hit a wall when they realize that the compat mode isn't exactly IE7 (there's many differences) and they still need to test in IE6.
So we fire up Virtual PC to test, download an IE6 and IE7 image and test away. Curse blue murder when we discover that the IE7 image has the screensaver set to lock-via-password after a 10min idle time! (we don't have the password!)
Ok, reboot and reset the screensaver.
Ok, so test in virtual IE6 and virtual IE7 and real IE8 after building and debuging in Firefox or Chrome.
phew what a painful process.
What is worse of course is that Mix10 is around the corner and IE9 will likely be showcased.
What new modes will IE9 bring? This testing matrix is becoming a bit nuts!
I can't speak for everyone, but I certainly ***DO NOT WANT*** to see any eye-candy new features (web slices,accelerators, etc.) in IE9
Dealing with yet another rendering engine (even though I WANT IT) will be hard enough.
More importantly we are expecting proper DOM nodeTypes, Event listeners, etc. and (quite frankly) will be quite disappointed if IE ships without them and instead includes a bunch of useless fluff.
Also missed in the flow chart:
missed the bit about IntRAnet vs IntERnet - where you test is in a different mode than where you deploy - for added developer confusion.
Woopsie! Don't press the F1 key in IE!
http://www.computerworld.com/s/article/9164038/Microsoft_Don_t_press_F1_key_in_Windows_XP
Good old VBScript zero-day vulnerability to compromise your PC.
As normal - installing ANY of the other, better browsers will ensure you don't get infected - even better still, when you upgrade your browser from IE to another browser you also get a better browsing experience!
DISCARD COM AND ACTIVEX NOW!!!!
DISCARD IEFRAME.DLL NOW!!!!
DISCARD GDI NOW!!!!
DISCARD ACTIVESCRIPT NOW!!!!
What we need:
* Managed code -- means NO memory leak.
* .NET Assemblies, not ActiveX DLLs
* BACKWORD COMPATIBILITY IS NEEDLESS
* DirectX, or WPF
* DLR
Microsoft has turned Visual Studio to WPF, Why not IE?
According to this scheme <meta http-equiv="X-UA-Compatible" content="IE=edge"> just doesn't work. Is it supposed to be so?
This post summarizes completely how much trouble you are causing to web developers with all the IE rendering modes (non of which on par with the other leading browsers). This is exactly why many developers have already suggested switching to an open source rendering engine like WebKit and keeping some [old] Trident version disabled by default just for "emergency cases".