I created a quick and dirty HTML file to demonstrate an issue I am encountering in IE compatibility mode. When I open it in IE8 from my desktop, it opens in standard mode. I need to be able to switch it to compatibility mode, but the icon for that disappears when I am viewing a local HTML document. What's up with that?
UPDATE: None of the three proposed solutions has resulted in the compatibility mode icon showing in IE8. Instead, I have put my code into an .aspx page and executed it through Visual Studio. Since it's originating from localhost, the browser thinks it is a remote document and is displaying the compatibility icon like I wanted.
However, if anyone can get this to work without having to do that, I am still open to ideas since launching a web app isn't really the ideal solution for me.
I'm not sure whether this'll work because of IE's many crazy exceptions and rules regarding local files and compatibility mode, but try the META tag approach.
In your <head>, for example say:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" >
See understanding compatibility modes to make sure you pick the right one.
You could try pressing F12 to open the developer toolbar, and change it in there.
Update: Have you tried tools > compatibility view settings > display all websites in compatibility view?
Users can override the ‘local
intranet’ setting by un-checking
‘Display intranet sites in
Compatibility View’ at Tools ->
Compatibility View Settings.
http://blogs.msdn.com/b/ie/archive/2009/06/17/compatibility-view-and-smart-defaults.aspx
None of the three proposed solutions has resulted in the compatibility mode icon showing in IE8. Instead, I have put my code into an .aspx page and executed it through Visual Studio. Since it's originating from localhost, the browser thinks it is a remote document and is displaying the compatibility icon like I wanted.
However, if anyone can get this to work without having to do that, I am still open to ideas since launching a web app isn't really the ideal solution for me.
Related
my html/css works fine with chrome, FF and IE11. Also with IE8 when loaded locally from my harddrive.
When the same files are located in an networkdrive the css seems not to work properly. Colors and fonts are fine, but some div-containers are displayed at the wrong positions.
When i transport the files in the htdocs of an apache fonts and colors are fine, but other problems occur with the positioning. Strangly not the same as when started from the networkdrive. Some divs are now correct, others ar now misplaced.
I´m not able to find any pattern with this.
I can check the behaviour within ff and chrome with the build-in dev-tools. But i don´t know of any similar tool within IE8.
Any idea for my 1001 attemp to fix the problem?
Thanks a lot!
Microsoft introduced different rendering modes for local and Internet servers so that web developers would break down in tears.
If there’s no X-UA-Compatible value and site is in Local Intranet
security zone, it will be rendered in EmulateIE7 mode by default.
Add X-UA-Compatible header or META to force full IE8 standards mode.
I have been reading up about document type emulating and compatibility mode in IE and have to say its quite a bit to get one's head around.
I have developed an App with Bootstrap 3 and Ember rendering a few pages controlled through a menu.
I tested this in all browsers, Webkit, Moz, and IE and all seemed perfect. I work in a large corporate, so when I decided to test it on some of my colleagues' computers, on IE, I got a blank page. Now I found that very strange because they were all running IE10 or IE11, although there is the odd IE9. I couldnt understand it because it renders perfectly on my IE.
So anyway, I started hitting F12 on their browsers and realised that many of them had IE7 emulating even though they were running IE10 or 11.
I read a bit about this issue, and I found the following:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9" />
So I proceeded to add this line to my page so it is as follow:
<!DOCTYPE html>
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9" />
Now my question is this: Am I correct in assuming that if there was some sort of group policy set when using IE at work, that this workaround would solve the issue?
I will do some testing tomorrow morning, but just wanted to know if that is along the right lines?
Many people at work use Chrome and Firefox or whatever they want to, but there are obviously quite a few that use IE.
Take note that there must be a reason why the current group policy is set to enable compatibility mode (some other intranet app maybe) and that other app might stop working (or render badly) if you disabled it. If the admin have configured it in a way where that there's a Compatibility View list then you're in luck because all you need to do is not include your web app's URL into that list.
https://msdn.microsoft.com/en-us/library/ie/gg622935(v=vs.85).aspx
As for the document mode, I suggest for you to use this instead:
<meta http-equiv="X-UA-Compatible" content="IE=edge">
Setting the version to 'IE=edge' tells Internet Explorer to use the
latest engine to render the page and execute JavaScript.
https://www.modern.ie/en-us/performance/how-to-use-x-ua-compatible
The only reason you want to "IE=EmulateIE9" is that your app is targeting the legacy document mode which in your case it isn't since you're using the latest web frameworks out there. I assume you want the best UI experience for your users.
I understand that in your case the IE versions vary and that some might not support "IE=edge". It will be just OK because it will fallback to the highest supported document mode. For example, IE8 with IE=9, IE=Edge, or IE=EmulateIE9 results in IE8 mode.
https://msdn.microsoft.com/en-us/library/ff405771(v=vs.85).aspx
IE uses different security zones for different types of content. Stuff from the Internet is loaded in the Internet zone. Stuff from the local network is loaded in the Intranet zone. If you go through Internet Options, you can see that there are different security settings applied to the various zones.
If you're deploying the app through the network, then your app is likely loading the app in the Intranet zone (right click the page and then choose Properties to confirm).
By default, IE loads intranet pages in compatibility view, which is the same as using EmulateIE7 as the content value for the x-ua-compatible element. This means that, absent additional tagging/changes, your app is being treated as if it were being viewed in IE7.
If you need a specific document mode, you should be able to specify that mode directly in the content value, e.g, content="ie=9". If that doesn't help, then try adding an MotW to the page, so that the page is loaded in the Internet zone. In turn, this should allow the x-ua-compatible setting to take effect.
You can also change the Compatibility View Settings, provided they're not disabled through GPO, so that Intranet pages aren't automatically loaded in compatibility view.
Hope this helps...
-- Lance
I work with a company that hosts a fair number of websites in a Perl ASP backend and we're trying to make sure our client's websites don't display the compatibility view button on the address bar of Internet Explorer unless absolutely necessary.
I've found one thing that triggers the button right away, which is including a javascript (in our case Jquery) file in the head section before the title and meta tags. However it's difficult to determine what makes IE think it should display the button beyond that (I'm testing in IE 10).
In testing one site that had the button displaying, I copied the page source code into an html file and tried viewing it locally. With identical source code, the live page displays the button while the local copy does not. Does Microsoft maybe do something similar to Google where a webcrawler indexes sites that might need compatibility view?
I find it's hard to get a straight answers as to who is really in control of this button and what aspects of a webpage contribute to the issue. Any help is appreciated.
IE will display the Compatibility View button unless you hide it by specifying the document mode using X-UA-Compatible via a HTTP response header or META tag.
Try using this document compatibility mode meta tag:
<meta http-equiv="X-UA-Compatible" content="IE=edge">
...that forces IE to use its latest standards mode.
I have a set of old html+JScript pages that are loaded from a local hard drive only. They used to work in previous versions of IE, but IE10 had something changed and it doesn't work anymore. I didn't write the code, so I don't think it's feasible to see what is broken, but it seems to work if I change IE into compatibility mode.
So I was curious, is there a command line parameter to launch IE in compatibility mode without altering the html file itself?
I think you meant to set compatibility settings to IE8, try
<meta http-equiv="X-UA-Compatible" content="IE=8" />
in head tag of html.
Under the Tools Menu bar, click on Compatibility Mode Settings. You can add all the sites where you want to run in compatibility mode there. More info here
I have just installed IE9 beta and on a specific site I created (HTML5) IE9 jumps to compatibility mode unless I manually tell it not to. I have tried removing several parts of the website but no change. Including removing all CSS includes. On some other website of me it goes just fine.
Also, don't set it manually because then IE9 remembers the user setting and you can't turn it back to automatic (or at least I haven't found how, not even via private browsing and emptying cache)
Anyway. The site where it jumps to compatibility mode: http://alliancesatwar.com/guide/
One where it renders correct: http://geuze.name/basement/ (I can't post more than 1 hyperlink)
Both use the same doctype and all. Those sites have a lot in common(apart from appearance) using the same basic template(encoding, meta tags, doctype and the same javascript)
It would be great if someone has an answer for me! An HTML5 website that renders in IE7-mode is pretty... lame.
Works in IE9 documentMode for me.
Without a X-UA-Compatible header/meta to set an explicit documentMode, you'll get a mode based on:
whether the user has clicked the ‘compatibility view’ button in that domain before;
perhaps also whether this has happened automatically due to some other content on the site causing IE8/9's renderer to crash and fall back to the old renderer;
whether the user has opted to put all sites in compatibility view by default;
whether IE thinks the site is on your intranet and so defaults to compatibility view;
whether the site in question is in Microsoft's own list of websites that require compatibility view.
You can change these settings from ‘Tools -> Compatibility view settings’ from the IE menu. Of course that menu is now sneakily hidden, so you won't see it until you press Alt.
As a site author, if you're confident that your site complies to standards (renders well in other browsers, and uses feature-sniffing to decide what browser workarounds to use), I suggest using:
<meta http-equiv="X-UA-Compatible" content="IE=Edge"/>
or the HTTP header:
X-UA-Compatible: IE=Edge
to get the latest renderer whatever IE version is in use.
I put
<meta http-equiv="X-UA-Compatible" content="IE=Edge"/>
first thing after
<head>
(I read it somewhere, I can't recall)
I could not believe it did work!!
To force IE to render in IE9 standards mode you should use
<meta http-equiv="X-UA-Compatible" content="IE=edge">
Some conditions may cause IE9 to jump down into the compatibility modes. By default this can occur on intranet sites.
I've posted this comment on a seperate StackOverflow thread, but thought it was worth repeating here:
For our in-house ASP.Net app, adding the "X-UA-Compatible" tag on the web page, in the web.config or in the code-behind made absolutely no difference.
The only thing that worked for us was to manually turn off this setting in IE8:
(Sigh.)
This problem only seems to happen with IE8 & IE9 on intranet sites. External websites will work fine and use the correct version of IE8/9, but for internal websites, IE9 suddenly decides it's actually IE7, and doesn't have any HTML 5 support.
No, I don't quite understand this logic either.
My reluctant solution has been to test whether the browser has HTML 5 support (by creating a canvas, and testing if it's valid), and displaying this message to the user if it's not valid:
It's not particularly user-friendly, but getting the user to turn off this annoying setting
seems to be the only way to let them run in-house HTML 5 web apps properly.
Or get the users to use Chrome. ;-)
The site at http://www.HTML-5.com/index.html does have the X-UA-Compatible meta tag but still goes into Compatibility View as indicated by the "torn page" icon in the address bar. How do you get the menu option to force IE 9 (Final Version 9.0.8112.16421) to render a page in Standards Mode? I tried right clicking that torn page icon as well as the "Alt" key trick to display the additional menu options mentioned by Rene Geuze, but those didn't work.
As an aside on more modern websites, if you are using conditional statements on your html tag as per boilerplate, this will for some reason cause ie9 to default to compatibility mode. The fix here is to move your conditional statements off the html tag and add them to the body tag, in other words out of the head section. That way you can still use those classes in your style sheet to target older browsers.
Looks fine to me:
You're sure you didn't on the settings globally or something? This is a clean installation of the beta on Windows 7. The developer tools report that the page is defaulting to IE9 Standard Mode.
I recently had to resolve this issue and here's what I did :
First of all, this solution is around tuning Apache server.
Second main think is that there's a bug in the IE9 which means that the meta tag will not work, instead of this solution try this
find/open your httpd.conf
uncomment/or add the following line
LoadModule headers_module modules/mod_headers.so
add the following lines
<IfModule headers_module>
Header set X-UA-Compatible: IE=EmulateIE8
</IfModule>
save/restart your Apache server,
browse to your page with IE9, use tools like wireshark or fiddler or use IE developer tools to check the header is there