Default IE8 Compatibility View breaks conditional comments

[David Mark]

I've discussed this issue recently with various developers and found
that it has not yet become common knowledge.

The good practice of using conditional comments to include CSS
adjustments for older IE versions has been broken by MS in IE8. The
default Compatibility View sets the "document mode" (rendering mode) to
IE7 standards mode, but leaves the "browser mode" as IE8. The browser
mode determines (among other things) which conditional comments will be
interpreted (and more to the point, which will be ignored).

The end result is that if the user inadvertently clicks the
Compatibility View button (prominently featured right next to the
refresh button), they get IE7-ish rendering without the benefit of IE <
8 CSS adjustments. How MS thought that would be a good default behavior
for this button is beyond my comprehension.

A way around this (at least for styles that are relevant only for
dynamic content) can be found at the top of the source for the My
Library Examples page.

http://www.cinsoft.net/mylib-examples.html

It's best to design around this when possible, but it is not possible
for a test page such as the above. For most sites, a
non-version-specific IE-only style sheet is all that should be required
(and normally shouldn't contain more than proprietary IE rules).

 

[David Mark]

| if (doc && typeof doc.documentMode == 'number' &&
| doc.documentMode < 8 && typeof doc.write != 'undefined') {
| doc.write(/* ... */);
| }
|
| if (typeof doc.compatMode == 'undefined' ||
| doc.compatMode.toLowerCase().indexOf('css') == -1) {
| this.document.write(/* ... */);
| }

Wouldn't it make sense to add `typeof doc.write != 'undefined'` to the
second `if` too?

Yes. Bad paste. The second came from another document where it was
already wrapped in such a test. Thanks for pointing that out.

And why `doc` in former, and `this.document` in latter?

Same. Thanks again!

Also, the assumption seems to be that if typeof `doc.documentMode` is
not "number" or "undefined", then it must be a string (judging by
`toLowerCase`, `indexOf` invocations). Do you find it safe to assume so?

Not in the slightest. That was sloppy of me. Thanks one more time!

 

[David Mark]

Ahh... Confused `documentMode` with `compatMode` Let me rephrase: is
it safe to assume `document.compatMode` is a string if it's not undefined?

I think our replies crossed in the mail. On further review, the above
is wrapped in a conditional comment, so will only be executed by IE.
And as the document is HTML (as opposed to XHTML, which IE9 will finally
support), the issues are really academic. IE definitely supports
document.write for HTML and document.compatMode is definitely a string
property when present.

But technically you are correct that you should always detect host
methods (and clearly I didn't mean to detect document.write in one
clause and not the other). And I suppose somebody could do this in IE5.x:-

document.compatMode = null;

....which would cause a problem in that version. I will clean it up when
I have a chance. Thanks again!

 

[David Mark]

The end result is that if the user inadvertently clicks the
Compatibility View button (prominently featured right next to the
refresh button), they get IE7-ish rendering without the benefit of IE <
8 CSS adjustments. How MS thought that would be a good default behavior
for this button is beyond my comprehension.

I can’t reproduce that, tried IE8 on XP SP3 and Windows 7, both with

[if IE 7]

and

[if lt IE 8]

When I press the ‘Compatibility View’ button ‘Browser Mode’ becomes
‘IE8 Compat View’ (not ‘IE8’) and conditional comments for IE 7 work.

Okay. If I switch it to that combination it works. But unless I am
mistaken, my IE8 on XP was failing to do that at one point. Regardless,
switching the Document Mode alone in the Developer Tools dialog creates
the problem. If only for that reason, I added the blurb at the top of
my Examples page. You can switch to quirks mode with that too, which
requires yet another workaround if you have CSS targeted at IE < 6.

What a confusing mess they made with that stuff.

Do you have test a case online that fails for you?

Yeah, the one I mentioned.

 

[David Mark]

The end result is that if the user inadvertently clicks the
Compatibility View button (prominently featured right next to the
refresh button), they get IE7-ish rendering without the benefit of IE <
8 CSS adjustments. How MS thought that would be a good default behavior
for this button is beyond my comprehension.

I can’t reproduce that, tried IE8 on XP SP3 and Windows 7, both with

[if IE 7]

and

[if lt IE 8]

When I press the ‘Compatibility View’ button ‘Browser Mode’ becomes
‘IE8 Compat View’ (not ‘IE8’) and conditional comments for IE 7 work.

Okay. If I switch it to that combination it works. But unless I am
mistaken, my IE8 on XP was failing to do that at one point. Regardless,
switching the Document Mode alone in the Developer Tools dialog creates
the problem. If only for that reason, I added the blurb at the top of
my Examples page. You can switch to quirks mode with that too, which
requires yet another workaround if you have CSS targeted at IE < 6.

What a confusing mess they made with that stuff.

Do you have test a case online that fails for you?

Yeah, the one I mentioned.

I played around with it a bit more and it seems that I had gotten so
used to the developer interface that perhaps I lost sight of what the
user interface did.

Or maybe I was remembering a combination using the third interface,
which is based on META tags (something I never use, but have
experimented with in the past). I cringe every time I see those in
production. IIRC, the myriad combinations (predictably) created havoc
for Dojo in its attempt to replace conditional comments with browser
sniffing logic. I think the UA string changes with the browser mode
(which sort of makes sense), but can't remember at this point. I
haven't cared about that end of it since I stopped paying attention to
Dojo's death spiral. Predictably, to this day, they tell users of old
Dojo versions, which "never claimed to support IE8" to include one of
those compatibility META's to try to make IE8 look like IE7.

Regardless, it doesn't change the validity of what I did on my Examples
page, but makes it less important (at least for those who are not
developers).

Again, what a mess. Whomever came up with the idea of all of those
different rendering/browser modes for IE8 must have been out of their
mind(s).