Forcing IE8 mode on the intranet

PS: if the IE8 in the intranet zone is configured for rendering all intranet as IE7 Compatible, then you are out of luck. You then need to change the IE8 settings.

Reference: http://msdn.microsoft.com/en-us/library/cc817574.aspx

That is the case for pages on the Internet.  I am on an Intranet (my URI doesn't have any dots in it except for the one delimiting the .aspx extension), and IE8 makes an exception for that.

According to http://blogs.msdn.com/ie/archive/2009/02/16/just-the-facts-recap-of-compatibility-view.aspx

"There are two cases where select Compatibility View features come pre-configured as part of IE's "smart defaults". For one, sites that map to the Intranet zone display in Compatibility View by default. This allows IE8 to be most compatible with line-of-business applications that expect IE7 behavior. (This can of course be changed by the user as well as configured via Group Policy.)"

Where does your reference say you are out of luck?  If you mean "The page is loaded in the Intranet zone and Internet Explorer 8 is configured to pages in the Intranet zone in Compatibility View.", that controls "default" rendering.  The whole point is to get past that "default".

If you could find a reference that confirms I am out of luck (which I suspect is true) I would be very grateful!

Oh...your validator link leads to a page for rent.

I think you meant http://validator.w3.org/

That's possibly in the context of "When Internet Explorer 8 encounters a Web page that does not contain an X-UA-Compatible header", assuming the scope of that clause is the section "Controlling Default Rendering" rather than just the paragraph.  Why can't they just write their descriptions in nice, readable C# instead of this ambiguous "English"!

Anyway, the phrasing is not clear.  Actual experimentation suggests your interpretation is correct, though, but it seems like an insane design choice - why WOULDN'T they allow an intranet to be transitioned slowly on a page-by-page base by respecting the X-UA-Compatible header?  It's not like there is expected to be an existing installed base of X-UA-Compatible headers, since this is a new item!

I agree that the phrasing is far from clear. It won't be the first time that I read and reread a text and still didn't get the point. But here, I think it really means what it, well, means.

On the slow transition: their idea is that you should do that on the servers: configure IIS or Apache to send the HTTP header for IE7 compatibility. Then, on a page by page, or site by site basis, you can override this header, either by changing it, or by setting the meta tag in HTML. Of course, this assumes that the IE8 browsers are configured normally.

Not that it helps, but I share your frustration :-)

-- Abel --

Unfortunately, "configured normally" is "configured to pages in the Intranet zone in Compatibility View"!

Which means all those headers are ignored....THAT'S what I find so senseless.

Quite nasty indeed. I assume you cannot persuade your network administrator to take this one step higher and use Firefox, Opera, Chrome or Safari instead? Any of these are allegedly safer (and often: reportedly safer), and developing for any of them is easier and quicker then developing for IE.

Well, I assume that's not much of an advice, as all large(r) companies I worked with stick to the oldest available browser by default (IE6), even after major security impacts or even breaches... I think you can be "happy" that you have a company that at least uses IE8 already.

What about configuring the default in the startup script of the users in AD? I can't help with the "how to" of that, but it shouldn't be too hard.

-- Abel --

No, it's pretty hard to convince all our customers (each has our app configured to their own intranet) to switch from IE.....but over 95% of the users are, as you lamented, IE6.  Just trying to get IE8 to work to be prepared, but we're probably going to have to warn them to override things on their browsers.

Painful solutions are still solutions, I kept this out a bit hoping there was something less painful.

Accurate to the best of my knowledge, anyway, and there are plenty of knowledgeable people here who had a shot if it wasn't!

> Painful solutions are still solutions, I kept this out a bit hoping there was something less painful.

just in case I find a new workaround or MS publishes something on the subject, I'll keep the post linked and update if I hear / find something that might be useful for you. Tx for the follow-up.

Thanks, dude!