New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conditional comments wrapping <html> prevent IE from honouring <meta http-equiv=X-UA-Compatible> #1187

Closed
djcsdy opened this Issue Aug 30, 2012 · 34 comments

Comments

Projects
None yet
@djcsdy

djcsdy commented Aug 30, 2012

This:

<!DOCTYPE html>
<!--[if lt IE 7]>      <html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]>         <html class="no-js lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]>         <html class="no-js lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js"> <!--<![endif]-->

prevents IE from honouring <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">.

When you think about it, it’s fairly obvious why. IE can’t process conditional comments until it knows what version it’s pretending to be, and it doesn’t know what version it’s pretending to be until it has processed X-UA-Compatible.

Symptoms:

  • Pages based on h5bp will render in compatibility view (meaning they render as if in IE7), if the user has turned that option on. Many users and administrators turn on compatibility view without realising what it does. (For pages with a properly working X-UA-Compatible, compatibility view is always turned off, which is what we modern web developers want).
  • All other IE users will see the ‘broken page’ icon in the address bar, which gives them the option to turn on compatibility view. (This harmful option is hidden for pages with a properly working X-UA-Compatible).

Image illustrating the ‘broken page’ icon in IE

It’s safe to wrap <body> instead, and just as useful (although this might break existing stylesheets if they rely on CSS classes being applied to the top-level element):

<!--[if lt IE 7]>      <body class="lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]>         <body class="lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]>         <body class="lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <body> <!--<![endif]-->

(I’m assuming that the no-js class should still be applied to <html>).

@patrickkettner

This comment has been minimized.

Contributor

patrickkettner commented Aug 30, 2012

There was actually an issue raised about this previously - #378

@djcsdy

This comment has been minimized.

djcsdy commented Aug 30, 2012

Closing as dup of #378

@djcsdy djcsdy closed this Aug 30, 2012

@roblarsen

This comment has been minimized.

Member

roblarsen commented Aug 30, 2012

Fwiw, the meta tag is far from foolproof. Unless you're completely handcuffed you should be setting the compar header on the server.

@djcsdy

This comment has been minimized.

djcsdy commented Aug 30, 2012

Fine. I usually do anyway but it’s handy to have for local testing.

It makes no sense to include in h5bp if it doesn’t do anything but looking at #378 I suspect arguing about it would just be pissing in the wind.

@necolas

This comment has been minimized.

Member

necolas commented Aug 30, 2012

You're saying it doesn't do anything? #378 says it simply doesn't prevent the compatibility view icon showing.

@djcsdy

This comment has been minimized.

djcsdy commented Aug 30, 2012

As it stands the IE=edge part has no effect whatsoever.

The chrome=1 part might work, I haven’t checked.

@jonathantneal

This comment has been minimized.

Member

jonathantneal commented Aug 30, 2012

If it has an effect on rendering I'm curious to see how this affects our view on XHTML compatibility.

@necolas

This comment has been minimized.

Member

necolas commented Aug 30, 2012

As it stands the IE=edge part has no effect whatsoever.

If that's true, then this isn't a dup of #378

If it has an effect on rendering I'm curious to see how this affects our view on XHTML compatibility.

How is it related to XHTML?

@martinnormark

This comment has been minimized.

martinnormark commented Dec 6, 2012

I've been trying to nail this IE compatibility icon for a long time, and the only thing that worked was to add the HTTP headers to the response.

Setting the X-UA-Compatible meta tag has no effect.

The only on-page change that solved the issue was to remove the conditional comments wrapping the HTML tag.

@AaronLayton

This comment has been minimized.

AaronLayton commented Dec 20, 2012

@djcsdy

As it stands the IE=edge part has no effect whatsoever.

Does this mean then instead of it being content="IE=edge,chrome=1" should it just be content="chrome=1" ?

@dmethvin

This comment has been minimized.

dmethvin commented Dec 20, 2012

I have a vested interest in making sure that H5BP doesn't let IE slip back into compat modes. jQuery 2.0 can't be used in IE 6/7/8, or in IE 9/10 where the user forces compat mode by accidentally clicking that infernal broken biscuit on the address bar. And yes, my scientific guess is that 90% of all clicks on the biscuit are accidental or misguided.

Using X-UA-Compatible in either an HTTP header or a meta tag will get rid of the biscuit so users don't click it. It also overrides any listing in Microsoft's Compatibility View list, which companies might need to do if they're using H5BP to redesign a site that currently is on that list. They can't get Microsoft to take their site off the list until the migration is complete, but they need their new design to override the CV list.

The absolute best way to avoid compat mode is for the site to send out the X-UA-Compatible HTTP header, because it avoids the need for IE to potentially restart a few lines down into the file when it sees the meta tag. However, a lot of companies have an organizational structure where the operations group that runs the server would never let some front-end Javascript jockeys tell them what headers they should send. So having a working X-UA-Compatible meta tag is the first line of defense.

If the tag isn't going to help this IE situation, it should just be pulled out because devs are going to see it there, search for X-UA-Compatible, and think it's protecting them from compat mode, when it's not. But I'd much prefer to see it actually work.

@necolas

This comment has been minimized.

Member

necolas commented Dec 28, 2012

Without a test-case showing exactly how this is different from the known issue of the 'compatibility icon' being displayed (which is distinct from the claim that IE renders the page in compatibility mode), there's no new evidence to justify removing this line of code or making some other related change. If someone has a test-case, we can move forward.

@dmethvin

This comment has been minimized.

dmethvin commented Dec 28, 2012

Start IE9 and go to this url: http://methvin.com/h5bp/ Your screen will look like this: http://i.imgur.com/WPkqp.png

Now press the Compatibility View button on the toolbar. The result is this: http://i.imgur.com/QcBY4.png

If the X-UA-Compatible tag in H5BP had its intended effect of removing that button and ensuring that IE ran in the most modern mode, it would not be possible to do this.

@necolas

This comment has been minimized.

Member

necolas commented Dec 29, 2012

Thanks. Please can you throw up a control page too.

@dmethvin

This comment has been minimized.

dmethvin commented Dec 29, 2012

I'm not sure what else you need, but if you describe your need for "throw up a control page" I can probably do it. That is a full stock install of h5bp 4.0.2, the only changes were to index.html and you can see those via view source.

@necolas

This comment has been minimized.

Member

necolas commented Jan 1, 2013

A control would be a "default" page against which the HTML5 Boilerplate code can be compared. In this case, it would be a page with the meta tag but no conditional comments around the opening html tag.

@dmethvin

This comment has been minimized.

dmethvin commented Jan 4, 2013

Here is the control page: http://methvin.com/h5bp/index2.html

Note that no compatibility view button appears on the address bar: http://i.imgur.com/yDJ68.png

@getsetbro

This comment has been minimized.

getsetbro commented Jan 29, 2013

Remove or add an empty conditional comment to the top: http://stackoverflow.com/a/14588826/1072149

Here is a page without: http://o0.getsetbro.com/tests/ie_compat_view_broke.html

Here is a page with it: http://o0.getsetbro.com/tests/ie_compat_view_fix.html

@dmethvin

This comment has been minimized.

dmethvin commented Jan 29, 2013

@getsetbro That does appear to fix it! Man it's ugly tho.

@wayferer

This comment has been minimized.

wayferer commented Jan 29, 2013

@getsetbro @dmethvin I had a look in IE10 on Windows 8 and didn't notice a difference...

@getsetbro

This comment has been minimized.

getsetbro commented Jan 29, 2013

@wayferer @dmethvin IE10 does not need the comment at the top. That is for previous IE's. IE10 ignores it. But it does need the X-UA-Compatible meta tag to NOT be wrapped in a comment like some solutions are advising.

@wayferer

This comment has been minimized.

wayferer commented Jan 29, 2013

@getsetbro Gotcha.

@dmethvin

This comment has been minimized.

dmethvin commented Jan 29, 2013

To be clear, when I said "fix it" I meant that will the leading comment IE9 doesn't show the compatibility view button on the URL bar, which is what I want since we don't want users to throw IE into compat view.

@getsetbro

This comment has been minimized.

getsetbro commented Jan 29, 2013

Right. It does not keep the Browser Mode out of Compatibility View but it
does keep the Document Mode in the latest Standards Mode that the version
of IE provides. The Document Mode determines the rendering engine. TBH I am
not sure what the impact is of it being in Compat Mode while the Doc Mode
is the latest. I haven't seen UI affects. I have gathered that it can
affect the UA String.

@getsetbro

This comment has been minimized.

getsetbro commented Jan 30, 2013

@dmethvin A different way to fix it would be to move the conditional
statements to the BODY tag instead of HTML. But I am guessing there is a
reason why they are not there.

@dmethvin

This comment has been minimized.

dmethvin commented Jan 30, 2013

In the original @paulirish blog post they were on the body, but were switched to the html tag. I'm not sure of all the history and pro/con behind it, although the blog post has a pretty decent audit trail.

@roblarsen

This comment has been minimized.

Member

roblarsen commented Jan 30, 2013

We moved it to the html element for performance reasons. As @dmethvin points out the whole story is captured in paul's post. I might write it up chronologically just for these discussions.

@backflip

This comment has been minimized.

backflip commented Feb 1, 2013

@roblarsen The post mentions performance issues with conditional comments around link tags, not the body tag. Am I missing something?

UPDATE: An additional empty conditional comment might be necessary: http://www.phpied.com/conditional-comments-block-downloads/#update

@roblarsen

This comment has been minimized.

Member

roblarsen commented Feb 1, 2013

Yeah, you're missing something. The conversation continued after the option of the empty comment was introduced (since people didn't like the empty comment.) A large part of the decision-making process on these kind of things happens in the comments.

I'll write up the chronology just for clarity.

@backflip

This comment has been minimized.

backflip commented Feb 1, 2013

That would be great, thanks!

@mendeza

This comment has been minimized.

mendeza commented Feb 4, 2013

Does this suggest that stepping back to the "empty conditional" fix shown by Stoyan is in fact the ugly but pragmatic path to take (assuming projects that must support oldIE)?

@victoriafrench

This comment has been minimized.

victoriafrench commented Feb 6, 2013

http://github.com/victoriafrench/defunctr would fix this. remove the conditional. Add class defunctr-ie-only to the html element. add the script after modernizr. There would be a difference in class names. Currenly this project uses .lt-ie8 etc. Defunctr uses .ie-lt-8 etc. But that is the only difference in generation.

@mendeza

This comment has been minimized.

mendeza commented Feb 6, 2013

@victoriafrench Defunctr looks really good (I'm gonna try it), but I fear we want to be setting this as close as possible to the first thing rendered, which is why using conditionals around <html> was/is so ideal. If we need to wait for JS, it may already be too late for certain use cases.

alrra added a commit that referenced this issue Sep 24, 2013

Remove IE conditional classes
The reasons behind this decision include the following:

* This project will drop legacy browser support (see #1050), therefore,
  the use for conditional classes for IE 8+, becomes much more limited.
* IE 10+ does not support conditional comments:
  http://msdn.microsoft.com/en-us/library/ms537512%28v=VS.85%29.aspx.
* Users do and can develop easily without using the conditional
  classes, this technique being very limited in scope as no other
  browser versions are explicitly target in the same way.
* It fixes the issue that prevents IE from honouring
  `<meta http-equiv="X-UA-Compatible" content="IE=edge">` (see: #1187).

This change also removes the related documentation.

Close #1290 and #1187.

@alrra alrra closed this Oct 21, 2013

rlovtangen referenced this issue in kodemaker/kodemaker.no Jan 8, 2014

Responsive tweaks
- bl.a sørg for at footer-tekst henger logisk sammen

kcmckell added a commit to kcmckell/html5-boilerplate that referenced this issue Feb 25, 2014

Remove IE conditional classes
The reasons behind this decision include the following:

* This project will drop legacy browser support (see h5bp#1050), therefore,
  the use for conditional classes for IE 8+, becomes much more limited.
* IE 10+ does not support conditional comments:
  http://msdn.microsoft.com/en-us/library/ms537512%28v=VS.85%29.aspx.
* Users do and can develop easily without using the conditional
  classes, this technique being very limited in scope as no other
  browser versions are explicitly target in the same way.
* It fixes the issue that prevents IE from honouring
  `<meta http-equiv="X-UA-Compatible" content="IE=edge">` (see: h5bp#1187).

This change also removes the related documentation.

Close h5bp#1290 and h5bp#1187.

rlovtangen added a commit to rlovtangen/grails-profile-repository that referenced this issue Feb 18, 2015

jameskleeh pushed a commit to grails-profiles/web that referenced this issue Jul 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment