Published 2012-02-06 06:23 by Leif Halvard Silli.
Or: My application for superhero status.
NOTE: On the same day I posted this post, version 3.0 of the HTML5 boilerplate was released. This post was written based on the previous version
and the subject of this article is line 12, which — due to the preciding code — is without effect on Trident’s parsing mode in IE8 and IE9 (it does however have effect on Chrome Frame, see below):
01.<!doctype html>
02.<!-- paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/ -->
03.<!--[if lt IE 7]> <html class="no-js ie6 oldie" lang="en"> <![endif]-->
04.<!--[if IE 7]> <html class="no-js ie7 oldie" lang="en"> <![endif]-->
05.<!--[if IE 8]> <html class="no-js ie8 oldie" lang="en"> <![endif]-->
06.<!--[if gt IE 8]><!--> <html class="no-js" lang="en"> <!--<![endif]-->
07.<head>
08. <meta charset="utf-8">
09.
10. <!-- Use the .htaccess and remove these lines to avoid edge case issues.
11. More info: h5bp.com/b/378 -->
12. <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">X-UA-Compatible works or not:Switch the last element from a edge-mode trigger …
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
… into a quirks-mode trigger:
<meta http-equiv="X-UA-Compatible" content="IE=5,chrome=1">
Now, if the X-UA-Compatible directive has any effect, then your copy of IE8 or IE9, will now be sent into to Quirks-Mode. (Tip: Use IE’s F12 tool to check the mode.)
Result: You should see that the page will remain in no-quirks mode — unless something else, like a setting in your copy of IE, tells it to behave differently. And thus we have verified that the X-UA-Compatible directive of the HTML5 boilerplate does not work.
An
X-UA-Compatiblealways work as long as it is kept outside a conditional comment.
Sorry! But not if there is a conditional comment before the meta element that contains the X-UA-Compatible directive.
One explanation of this odd behaviour could be that conditional comments block downloads.
But one could also simply use one’s brain to explain it: Conditional comments affects IE’s parsing — it decides which elements it sees, depending on which version of IE the conditional comments are targeting. At the same time, the X-UA-Compatible directive affects exactly which version your copy of IE considers itself to be: If it tells IE to move to IE5 mode (AKA quirks-mode), then it will react to other conditional comments than those it might react to if it stayed in no-quirks mode. So when it sees — and reacts to — conditional comments before it sees the X-UA-Compatible, then it kind of makes sense — at least to this author — that IE considers it “too late” to bother about X-UA-Compatible when IE already has read and interpreted a conditional comment.
One could also look at it from a historical angle: Microsoft invented conditional comments long before they came with X-UA-Compatible — which might explain why they kind of fail to co-operate.
Why X-UA-Compatible still works if one places a conditional comment or no condition comment before the DOCTYPE? Perhaps it is due to some kind of alert mode that gets triggered by this? Just speculation. Which makes some sense.
Conditional comments around the
<html>element fixes the (blocking) issue.
One comment on Stoyan’s conditional comment page links to a page by Jeffrey Barke that claims that the issue can be solved exactly by the code found in the HTML5 Boilerplate. That page claims to have test pages, but the links to those tests are rotten, and so we can only guess how he arrived at that conclusion.
However, it is not accurate that there is such a relationship!
What is true, is that if a page begins (that is: before the DOCTYPE) with a conditional comment or with a no condition comment, then the blocking is removed. This is also basically what Stoyan ends up with.
So if Jeffrey Barke’s test pages began with conditional comments (i.e. if he tested without the DOCTYPE), then his tests would work as he claims. But when the page begins with a no-quirks triggering DOCTYPE, then it is that “directive” (the DOCTYPE) that triggers no-quirks mode — and not the X-UA-Compatible. To verify this, you must — as explained above — try to set the page in quirks-mode via X-UA-Compatible.
Chrome Frame does not read inside
<!--[if ie]><![endif]-->.
At least Jeffrey Barke presented the view that Chrome Frame ignores IE conditional comments, so it [Chrome Frame] never gets invoked
. However, I belive it is a widespread view.
However: This too is not true. At least not for the moment: Chrome Frame will always read inside conditional comment, because Chrome Frame simply ignores whether the conditional comment says [if IE] or [if !IE]. (Probably it isn’t correct to say that Chrome Frame reads inside, but that IE reads inside — but that’s a technical detail.)
X-UA-Compatible directive in the HTML5 Boilerplate currently only works for Chrome Frame …DOCTYPE — the boilerplate will then work in IE to without any other changes.
DOCTYPE is mandatory!X-UA-Compatible directive inside a conditional comment — it both makes the page valid and prevents that IE10 eventually gets affected. (IE10 will not get affected except if the DOCTYPE is invalid or lacking — however, even such effects should be avoided.)X-UA-Compatible directive outside conditional comments, but before the first conditional comment.In a summary: There are no negative sides related to wrapping the X-UA-Compatible directive inside a conditional comment, in combination with placing a empty cond-com before the DOCTYPE.
PS: This article was inspired by a comment in Stack Overflow which pointed to the issue with the HTML5 boilerplate.
Note: I have now, since I wrote the above, edited the Stack Overflow answer that inspired this article to reflect the findings that I have documented on this page — provided it gets an OK by the peer reviewers, you will essentially find the essence of this articel there too.
© 2013 Leif Halvard Silli