Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This is a best practice offered by HTML5Boilerplate. It forces IE to use the most recent rendering engine or to use Chrome's frame rendering engine if available.
More info here.
Comment | File | Size | Author |
---|---|---|---|
#26 | add-x-ua-compatible-1203112-26.patch | 742 bytes | dubois |
#17 | add-x-ua-compatible-1203112-17.patch | 782 bytes | dcmouyard |
#11 | ie.jpg | 48.54 KB | droplet |
#2 | ie_ua_com_edge.patch | 917 bytes | droplet |
Comments
Comment #1
sherakama CreditAttribution: sherakama commentedI do like this practice. In fact I have been adding it to all of my themes through the preprocess_html hook in the template.php file.
+1 for core implementation.
Until it makes it way into core those using D7 can ...
Comment #2
droplet CreditAttribution: droplet commentedComment #3
idflood CreditAttribution: idflood commentedI do like the idea but there are two problems:
- breaks validation
- there is a cleaner way of doing it that doesn't break the validation
This line breaks validation, and the Chromeframe part won't work inside a conditional comment. One workaround is to use the apache/nginx/IIS/lighthttpd configuration to send these as headers instead. You also might want to read Validating: X-UA-Compatible
from: http://html5boilerplate.com/docs/The-markup/#make-sure-the-latest-versio...
Comment #4
droplet CreditAttribution: droplet commentedI think
- Drupal isn't 100% valid markup. eg. CSS prefix.
- .htaccess isn't a requirement of Drupal.
- it able to config it without this markup
Comment #5
droplet CreditAttribution: droplet commented.htacces way isn't work safely. I did some tests.
I tried
curl -I -L http://192.168.56.108/drupal7x
curl -I -L http://192.168.56.108/drupal7x/
verify it working:
curl -I -L http://192.168.56.108/drupal7x/misc/jquery.js?v=1.4.4
more:
curl -I -L http://192.168.56.108/h5bp/index.html
curl -I -L http://192.168.56.108/h5bp/index.php
Comment #6
ericduran CreditAttribution: ericduran commentedThis shouldn't be done here. Instead of doing it in the head we should just sent the header the same way we send the content-type header.
have a look add drupal_deliver_html_page where we probably should add "drupal_add_http_header('X-UA-Compatible', 'IE=edge,chrome=1');"
Comment #7
droplet CreditAttribution: droplet commentedGood suggestion. Postponed form this issue #1400800: drupal_send_headers doesn't unset headers
Comment #8
adnasa CreditAttribution: adnasa commentedI'm for IE-edge in core since it forces IE to use the most current rendering engine, but I'm hesitant about chrome frame. This is because
chrome=1
would also hint the user to install the chromeframe plugin if not available and that's not exactly optimal from a user experience perspective (I wouldn't want this on every drupal installation afterall). We can makechrome=1
optional though through the theme layer.Comment #9
droplet CreditAttribution: droplet commented@adnasa
chrome=1 won't hint user to install anything.
Comment #10
ericduran CreditAttribution: ericduran commentedAs mention by @droplet chrome=1 won't prompt users for anything. It'll just makes IE use chrome frame if it's installed if not IE still uses the latest rendering engine.
Comment #11
droplet CreditAttribution: droplet commentedIt's why we should add it:
Comment #12
cosmicdreams CreditAttribution: cosmicdreams commentedHTML5 boilerplate (3.0) no long applies chrome frame by default http://html5boilerplate.com/ . I still lean towards committing the patch in #2 anyway, but I have seen this question posted here yet?
Are we making Drupal 8 harder to troubleshoot by doing this. I'm imagining a future where I get a lot of support calls where User A and User B are "running the same browser" but one is seeing an issue while the other isn't. Then I have to do a
have you flushed the cache,reboot and try again, "I mean does the one that works have ChromeFrame installed?" test to see if that's the issue. And then tell the one that doesn't to install Chrome Frame.Comment #13
droplet CreditAttribution: droplet commentedAFAIK, H5B only removed chrome frame installation script.
https://github.com/h5bp/html5-boilerplate/blob/master/index.html
I just afraid it do not work with Chrome Frame installed. I have no experience of this problem.
another choose is only bring unsupported IE into chrome frame.
Comment #14
cosmicdreams CreditAttribution: cosmicdreams commentedI like #13 a lot!
Comment #15
JohnAlbinWe'd need this header for #1471382: Add IE-conditional classes to html.tpl.php as well.
Comment #16
cosmicdreams CreditAttribution: cosmicdreams commentedcool, looks like all we need here is an updated patch and consensus. I'll make a new patch for this tonight, if no one beats me to it.
Comment #17
dcmouyard CreditAttribution: dcmouyard commentedI agree with @ericduran in #6 that this should be set via HTTP header rather than set as a
<meta>
element in<head>
.If #1471382: Add IE-conditional classes to html.tpl.php gets into core, then using the HTTP header method avoids a bug where IE displays a compat view icon when the
<html>
element is wrapped in IE-conditional comments.Comment #18
JohnAlbinI verified that the format of the X-UA-Compatible header is correct; the "IE=edge,chrome=1" with a comma is correct. The value pairs in this header need to be separated by semi-colons, but we really do want to set "IE" to the value "edge,chrome=1".
I looked at the code and saw that it is correctly checking if the header is already set before adding it. http://api.drupal.org/api/drupal/core%21includes%21bootstrap.inc/functio...
I did some curl tests on my server before and after applying the patch and the X-UA-Compatible header shows up properly on all Drupal-generated pages.
The problems droplet had in comment #5 don't occur since we're not using .htaccess to add the header.
Comment #19
catchThis looks fine and I don't think we need a test for it (#18 suggested we might, but all we could do is verify in the test that it matches what we have in the code, not that it's correct).
So I've committed/pushed this to 8.x. Since it's going to affect IE rendering, seems like we could use a change notice to document that we're now sending this header and the effect it'll have.
Comment #20
droplet CreditAttribution: droplet commentedand anyone have time please review #1400800: drupal_send_headers doesn't unset headers, make sure we can totally unset the headers:
Comment #21
JohnAlbinI need to review this for the Zen theme. I'll write the changelog.
Comment #22
JohnAlbinChange record is here: http://drupal.org/node/1511040
Comment #23
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedComment #24
klonosWould D7 also benefit from this? Any API changes?
I know this is about markup and not the UI, but I believe this is related: #1505456: Add a "Backports" or "Drupal update" module to Drupal 7 core so that UI changes from Drupal 8 can be backported
Comment #26
dubois CreditAttribution: dubois commentedAttaching same patch but for D7 and including in makefiles.
Comment #27
tlattimore CreditAttribution: tlattimore commentedI can confirm that the patch attached in #26 applies cleanly and works as described. Tested by appling to a D7 install and running IE8 in compatibility view. It is clearly passing the right header and forcing IE into edge mode.
Comment #28
klonos...ok then. Lets see if we can get this in D7.
Comment #29
ericduran CreditAttribution: ericduran commentedIDK if it's worth getting this in D7.
D7 core doesn't really require IE edge as much as D8 stuff.
Also there's about 10 contrib modules that do this in D7.
I would say we can just close this issue and be done with this one.
Comment #30
StephanieFuda CreditAttribution: StephanieFuda commentedHey ericduran,
I could use this in 7, since I'm often stuck using older versions based on exsisting builds.
You mention that there are contrib mods to do this, can you list them? I couldn't find them.
Thanks!
Comment #31
tlattimore CreditAttribution: tlattimore commented@Stephanie_42 - If you have a custom module for your site you can achieve this o this in
hook_init()
. I have the used the following in hook_init for a site:See this snippet for an example in more context.
I agree with ericduran's statement in #29 & don't think this is needed in D7 core, so I am going to mark this as fixed. If anyone wants to make an argument for this in D7 they can reopen..
Comment #32
klonos...marking this fixed against 7.x might give the wrong impression that it was actually backported.
Comment #34
jbrown CreditAttribution: jbrown commentedYou have to do it like this in Drupal 7 as, unlike Drupal 8, Drupal 7 does not store HTTP headers in the page cache:
Comment #35
adnasa CreditAttribution: adnasa commentedThis issue is still about chrome frame, right?
http://blog.chromium.org/2013/06/retiring-chrome-frame.html?m=1
Comment #35.0
adnasa CreditAttribution: adnasa commented...link changed ;)
Comment #36
tixiv CreditAttribution: tixiv commentedShouldn't we remove the ",chrome=1" part?
The Google Chrome frame is retired:
http://blog.chromium.org/2013/06/retiring-chrome-frame.html?m=1
This is the discussion from the html5 boilerplate team.
https://github.com/h5bp/html5-boilerplate/pull/1396