Say, which browser is missing from the lists I just mentioned? Right! The very one which is our official platform. Like my boss says, “if it ain’t working on IE8, it ain’t working.” If I was a real web designer, and not a poseur wanna-be services developer, I’d wake up in cold sweats at night with those words echoing in my ear!
Actually, it works well and looks pretty good in IE8, too… most of the time (doesn’t look quite as awesome as the other browsers, but good enough).
But some of the time it doesn’t work and looks awful. Even on my own laptop it used to change; sometimes it would work well and look good, and sometimes it wouldn’t work and look awful. WTF??
So I discovered the F12 key. In IE, F12 brings up Developer Tools. In the upper right, you can see which “compatibility view” IE8 is using. Quickly I found the pattern:
- If IE8 works well and looks pretty good, it has decided to use IE8 mode
- If IE8 doesn’t work and looks awful, it has decided to use IE7 mode, or even “quirks mode”
Our user experience designer jumped right on the problem, and found the “X-UA-Compatible” setting. If you add this setting to your page header, you can advise IE8 which mode to use:
<meta http-equiv="X-UA-Compatible" content="IE=edge">
The “edge” part tells IE to use the lastest mode; so our forward-looking users using IE9 get to see IE9 mode.
But even after this fix, sometimes I would see our development site in IE7 or quirks mode! What is up with that?
Eventually I found an MSDN page purporting to explain compatibility modes in IE 8. The real valuable part of this article was in one comment:
The “display intranet sites in compatibility view” check box will override any meta tag or http header you put in the server or on the web page. There is nothing you can do except uncheck that box. Yes, this is a dumb design and it runs completely contrary to all available documentation but according to MS tech support it is “by design”.
So I found that checkbox. It is under Compatibility View Settings:
And sure enough, our development web site is in the “Local Intranet” zone. I unchecked that box, and ever since, IE8 works well and looks pretty good!
Of course, from a delivery perspective, this is pretty bad news. We can put headers and meta tags in our webapp all day long, but if our users are stuck in the “local intranet” zone and haven’t unchecked this box, IE8 will probably not work and look awful! As far as I can tell, there is nothing we can do about it!
“If it’s not working in IE8, it’s not working”… My cold sweats are starting!
Couple of things, since we are working on the same web application I noticed the following:
1. Before logging into the webapp, I checked the Compatibility Settings, it was Browser Mode = IE8, Document Mode = IE7 Standards.
After logging into the webapp, checked Compatibility Settings, it was Browser Mode = IE8, Document Mode = IE8 Standards, but there were still strange things occurring in the webapp.
What I found: Need to clear the cache from the domain (Ctrl-D in Developer Tools), logout, and then login again to see the webapp work.
2. Also, I checked my IE8 settings – and the “Display Intranet sites in Compatibility View” checkbox was checked, and the web application seemed to work after I did the steps stated in number 1 above.
Seems there are more strange things in IE8 that needs to be investigated…
Rats, and I thought I had understood what was really happening. Apparently the depths of IE remain unplumbed! For me, with the “Display Intranet Sites in Compatibility View” unchecked, the whole site is always in IE8 mode, including the login page. However, some parts of it still don’t work right, including the paging controls and some of the menu highlight mouseovers.
I’m not sure why the same browser, with the same settings, with the same site, in the same zone (Local Intranet), shows different behavior. Back to my original question: WTF happened to my webapp???