Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Default IE8 Compatibility View breaks conditional comments

Reply
Thread Tools

Default IE8 Compatibility View breaks conditional comments

 
 
David Mark
Guest
Posts: n/a
 
      05-12-2010
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).
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      05-12-2010
kangax wrote:
> On 5/12/10 3:53 AM, David Mark wrote:
>> 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).

>
>
> | 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!
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      05-12-2010
kangax wrote:
> On 5/12/10 9:56 AM, kangax wrote:
>> On 5/12/10 3:53 AM, David Mark wrote:
>>> 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).

>>
>>
>> | 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? And why `doc` in former, and `this.document` in latter?
>>
>> 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?

>
> 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!
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      05-12-2010
Eric Bednarz wrote:
> David Mark <(E-Mail Removed)> writes:
>
>> 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.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      05-13-2010
David Mark wrote:
> Eric Bednarz wrote:
>> David Mark <(E-Mail Removed)> writes:
>>
>>> 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).
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ie8!=ie8 cecile Javascript 2 05-24-2010 09:04 AM
Re: Advantages of IE8/64 over IE8/32 PA Bear [MS MVP] Windows 64bit 0 08-17-2009 09:43 PM
IE8 Browser Compatibility compukid007 Software 1 11-12-2008 12:27 AM
Re: Microsoft breaks IE8 interoperability promise Dave Doe NZ Computing 8 09-01-2008 04:30 AM
? ELSE Conditional Comment / Using Conditional Comments Inside Other Tags To Comment Out Attributes Alec S. HTML 10 04-16-2005 02:21 AM



Advertisments