homepage Welcome to WebmasterWorld Guest from 54.211.95.201
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderators: not2easy

CSS Forum

    
What do all these IE Modes really mean?
compatibility, standards, quirks..
SuzyUK




msg:3949486
 7:10 pm on Jul 9, 2009 (gmt 0)

The post below contains relevant snippets from a previous post [webmasterworld.com] which forked into more interesting discussion about IE's compatibility modes, which we really thought deserved it's own thread!



...it is/was always possible to put IE7 into quirks mode, it just didn't happen with the existing <xml prolog> thingie used in the previous code.. you simply need to put a comment, any comment, before the Doctype instead

What I learned...
it is possible to put IE7 into quirks mode without IE8 trying to go into its 'special' IE7 mode (and no this is not the emulation mode)

IE state that they use the Doctype to determine the compatibility mode for IE8, if no emulation mode is specified.

EmulateIE8 mode is similar to EmulateIE7 mode; Internet Explorer uses the <!DOCTYPE> directive to determine how to render content; however, standards mode directives are displayed in Internet Explorer 8 Standards mode. Quirks mode directives are displayed in IE5 mode.

So that's OK.. we know that but we also know that IE doesn't quite always get it right, so what if you hide the (IE only part of the) "quirky" part of the Doctype from IE8? - I tried it it works :) Good ol' Conditional comments

<!--[if lt IE 8]><!-- IE6 & 7 quirks mode --><![endif]-->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" ><head>
<title>3 Column CSS Layout - Fixed Header and Footer</title>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
<style type="text/css" media="screen">
html, body {height: 100%; width: 100%; margin: 0; padding: 0; border: 0;}

/**** some general formatting styles **********/
body{font-size: 0.8em; font-family: verdana, tahoma, arial, sans-serif;}

a {
color: #fff;
background: transparent;
text-decoration: underline;
}

a:hover {color: lime;}

.tablecell a {color: #009;}

.tablecell a:hover {
color: #fff;
background: #009;
text-decoration: none;
}

ul {padding-right: 0.5em;}

p {margin: 0;}

.two p {line-height: 4;}

h1, h2, h3 {font-family: georgia; padding: 0; margin: 0.5em 2em;}
h1 {font-size: 1.2em;}
h2 {font-size: 1.1em;}
h3 {font-size: 1em;}
/*** end general ***/

.thetable {
position: relative;
display: table;
width: 100%;
height: 100%;
}

.tablerow {display: table-row;}

.tablecell{
display: table-cell;
border: 0;
padding: 100px 0 50px 0;
margin: 0;
vertical-align: top;
height: 100%;
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}

.one{
width: 180px;
background: violet;
position: relative;
border-right: 1px dotted #000;
z-index: 5;
}

.two{
width: auto;
background: yellow;
position: relative;
}

.two .pad {
padding-left: 20px;
padding-right: 20px;
}

.three{
width: 200px;
background: lime;
position: relative;
border-left: 1px dotted #000;
}

#header{
position: absolute;
background: #000080;
width: 100%;
height: 100px;
color: #fff;
z-index: 10;
border-bottom: 2px dotted lime;

-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}

#footer{
margin-top: -40px;
width: 100%;
background: #000080;
color: white;
min-height: 40px; /* IE lt 7 needs height though */
position: absolute;
z-index: 100;
}
</style>

<!--[if lt IE 8]>
<style type="text/css" media="screen">

.thetable, .tablerow {display: block;}
.tablecell {float: left;}

/* middle cell adjustments for IE floats */
.two {
width: 100%;
margin-left: -180px;
margin-right: -200px;
padding-left: 200px;
padding-right: 220px;
}

/* added, using the * html hack to overcome min-height rules in IE 6 and below */
* html .tablecell {height: 100%;}
* html #footer{height: 40px;}
</style>
<![endif]-->

</head>
<body>
<div id="header"><h1>3 Column CSS Layout <span>a work in progress&#187;</span></h1>
</div>
<div class="thetable">
<div class="tablerow">
<div class="tablecell one"><div class="pad">
<p>CSS - 100% Height layout.</p>
<ul>
<li>three column stretch</li>
<li>fixed height header and footer</li>
<li>footer spans 3 columns</li>
</ul>
<p><a href="#">test link</a></p>
</div></div>
<div class="tablecell two"><div class="pad">
<h2>Middle Column</h2>
<p>This is a flexible width column, in IE6/7 it is the width of the screen and clearance of the side columns in <strong>IE</strong> is produced by <em>extra left and right padding</em>.</p>

<p>add in lots of foo text to see columns stretch, and footer move down</p>
<!--
<p>foo</p><p>foo</p><p>foo</p><p>foo</p><p>foo</p><p>foo</p><p>foo</p>
<p>foo</p><p>foo</p><p>foo</p><p>foo</p><p>foo</p><p>foo</p><p>foo</p>
-->

</div></div>
<div class="tablecell three"><div class="pad">
<p>This version is done using IE conditional CSS.</p>
<p>IE6 &amp; 7 Quirks still required - trigger with a comment before the Doctype</p>
</div></div>
<!-- tablerow --></div>
<!-- thetable --></div>
<div id="footer"><!--<p>and this of course is the footer</p>--></div>
</body>
</html>

[edited by: SuzyUK at 9:55 am (utc) on July 12, 2009]

 

jameshopkins




msg:3949886
 9:54 am on Jul 10, 2009 (gmt 0)

IE state that they use the Doctype to determine the compatibility mode for IE8, if no emulation mode is specified

EmulateIE8 mode is similar to EmulateIE7 mode; Internet Explorer uses the <!DOCTYPE> directive to determine how to render content; however, standards mode directives are displayed in Internet Explorer 8 Standards mode. Quirks mode directives are displayed in IE5 mode.

IE8's Standards Mode and Compatibility View (or Mode), is whole different kettle of fish to Standards Compliance Mode and Quirks Mode.

As far as I'm aware, both Standards Mode (IE8 mode) or Compatibility View (IE7 mode) in IE8 can only be invoked either a) by speciying the relevant HTTP Header or META declaration, and b) as a result of telemetry data (concerning which mode visitors to your site use). Although IE8 Standards Mode is the default rendering engine - and is used if no emulation mode is specified - Compatibility View can also be invoked when IE8 comes across a critical error that it can't recover from when in IE8 Standards Mode; I've documented several bugs - with the cause being certain combinations of CSS properties - that trigger this behaviour.

There is nothing in a W3C-recognised doctype that determines which one of these IE8-specific 'modes' is used; like all other browsers, all Doctypes (excluding XHTML Transitional (without system identifier)) will invoke the recognised Standards Compliance Mode in IE8. Also, just like other browsers, a document omitting a Doctype, will be rendered in Quirks mode.

it is possible to put IE7 into quirks mode without IE8 trying to go into its 'special' IE7 mode (and no this is not the emulation mode)

What do you mean when you say "'special' IE7 mode"?. FYI, you can invoke Quirks Mode in IE8 either by, a) placing a comment before the Doctype, or b) placing a comment between the XML prolog and Doctype.

if IE6 & 7 are in quirks mode you can get other browsers to act the same by using the afore mentioned CSS box-sizing property though they may require a little prefix help

FYI, Firefox requires '-moz-', Webkit requires '-webkit-' and Opera can use the property without the vendor extension prepended.

SuzyUK




msg:3949913
 10:24 am on Jul 10, 2009 (gmt 0)

FYI, Firefox requires '-moz-', Webkit requires '-webkit-' and Opera can use the property without the vendor extension prepended.

I know, they're in the code ;) and as noted in my comments as long as the non-prepended version comes last of the 3 in the rules it should be good to go going forward too

about the comments before the Doctype triggering quirks, I also know that.. what I didn't know was that using a conditional comment (an HTML comment!) around it would hide it from IE8. Using a comment to hide a comment just seems a bit weird - anyway I want IE8 to be standards mode for this template so it can use the table properties. What I learned is that we can have IE6&7 in quirks mode and not IE8.. Why would anyone want to put 8 into Quirks when it's got all those lovely new properties to take advantage of ;)

SuzyUK




msg:3949961
 11:28 am on Jul 10, 2009 (gmt 0)

@james

Although IE8 Standards Mode is the default rendering engine - and is used if no emulation mode is specified

I was just reading the MS Documentation [msdn.microsoft.com] trying to find out the proper way to force IE into IE8 standards rather than my hacky CC workaround, and I think the default rendering must must be Emulate IE8 mode rather than IE8 standards mode? (I didn't even know Emulate=IE8 existed! but that's obviously the correct terminology for the 'special IE7' mode I mentioned in first post :o)

Emulate IE8 mode tells Internet Explorer to use the <!DOCTYPE> directive to determine how to render content. Standards mode directives are displayed in Internet Explorer 8 standards mode and quirks mode directives are displayed in IE5 mode. Unlike IE8 mode, Emulate IE8 mode respects the <!DOCTYPE> directive

My bold

Sure enough if I remove the conditional from around the comment it goes into quirks mode in IE8 too (like IE5 mode), i.e. it's 'respecting' the Doctype directive, well the way it used to anyway. Then if I force IE8 mode using the meta tag it goes back into standards (same as my conditional in the code above was doing)

that's a little deceptive is it not? I too thought the default mode was IE8 standards mode. What do you think, is this liable to have any other consequences, catch others out?

jameshopkins




msg:3950120
 3:11 pm on Jul 10, 2009 (gmt 0)

IE8 Standards mode and Compatibility View
I was just reading the MS Documentation trying to find out the proper way to force IE into IE8 standards rather than my hacky CC workaround, and I think the default rendering must must be Emulate IE8 mode rather than IE8 standards mode? (I didn't even know Emulate=IE8 existed! but that's obviously the correct terminology for the 'special IE7' mode I mentioned in first postv

Just so we're clear, by default, IE8 renders pages in Standards mode - the engine that Microsoft claims to be fully CSS 2.1 compliant (but isn't).

Emulate=IE8 is an option in both the HTTP Header and META declarations which can either:-

  • force IE8 to use Standards mode if for any reason pages were being rendered in Combatibility View.
  • be used as a pre-emptive measure to ensure that pages are never rendered in Compatibility Mode.

If either the HTTP Header or META declaration is set to Emulate=IE8,

  1. the Compatibility View button in the users browser will dissappear, ensuring Compatibility View can never be invoked by that user.
  2. any settings related to Compatibility View in the users own locally-compiled list that apply to your domain, will be overruled.
  3. invoking Compatibility View based on the telemetry data in the community-shared Compatibility list, will be overrruled.
  4. 'hard asserts' (critical errors) won't be recoverable, since the browser can't fall back to Compatibility View mode. This is a very serious issue

A note on #3. Although specifying either Emulate=IE8 declaration will overrule any Compatibility list settings that apply to your domain, your domain won't get removed from the list.

Removing your site from the Compatibility View list
If you want to remove your site from this list, you'll need to retain this Emulate=IE8 declaration in your document. Next, you have to place a file named 'IEStandards.xml' in the root folder of your domain. In the XML file, you need to define a root element of '<IE8StandardsMode/>'.

The recognised Standards Compliance & Quirks mode

Sure enough if I remove the conditional from around the comment it goes into quirks mode in IE8 too (like IE5 mode), i.e. it's 'respecting' the Doctype directive, well the way it used to anyway. Then if I force IE8 mode using the meta tag it goes back into standards (same as my conditional in the code above was doing)

I'm unsure as to what you mean here.

You are correct in assuming the comments preceding the Doctype will invoke Quirks mode in IE8. However, I'm unsure as to what exactly you want to achieve here; invoking Quirks mode is a completely seperate process (or so I thought) to determining whether IE8 Standards mode or Compatibility View were being used. Quirks reverts to a far earlier rendering mode than Compatiblity View (emulating IE7 does). Just to clarify, what you're saying is, you firstly invoked Quirks mode and then Quirks mode was subsequently overruled by specifying the META declaration?!

SuzyUK




msg:3950640
 12:41 pm on Jul 11, 2009 (gmt 0)

OK I'm having real difficulty getting my around all these modes.. that'll be the ones we shouldn't have to be dealing with anyway.. but in the interest of trying to help IE get there I'm trying to be patient!

Just so we're clear, by default, IE8 renders pages in Standards mode

That's the bit I'm not believing, or at least I'm not finding it clear by any stretch of the imagingation.

By default they are rendering the pages in either Quirks or Standards Rendering Mode depending on the version of "IE standards" they have set in the past, (they really should use their own terminology). The fact that they allow a comment before a STANDARDs compliant Doctype to even trigger their own little Quirks Mode should no longer be available by default. Those who have taken, or now want to take advantage of it for backwards compatability (like hacks) can choose to serve their sites in IE7 Compatibility view for minimal interruption.

The very strictest IE8 mode does indeed take that 'feature' away, forcing standards compliant rendering mode by ignoring IE's quirky triggers, - but that is not the default. The default IE is using is Emulate=IE8. It honours IE Quirks mode (non standard) triggers. Which begs the question, why would anyone want to 'Emulate' IE8 yet, maybe come 9 but now?

If authors are updating a site or documents to be IE8 compatible surely it's because they want to take advantage of their better support of CSS2.1 which requires the Document not be in Quirks rendering mode.

e.g. if I didn't have time yet to figure out any/all changes a site might require in one go, then I would choose Emulate=IE7 mode (or force compatibility view) until such times as I was confident to make the switch, but then it turns out we SHOULD have some sort of IE8 meta anyway in order to "trim" our sites from users lists if they've already chose to put our sites in compat view themselves.

So what they're really saying is that all authors have to use a meta tag (or this XML file) of some sort regardless of what they're trying to do.

What I was getting at, when real-worlding a scenario like the code sample above, and in fact any IE coding I've done up until this point, is say some of us have been ready for this switch for a long time and have taken steps, like they asked us to since IE7, to keep IE6/7 CSS separate in conditional comments, we were ready for IE8. But now we still have to in there and either update the conditionals to include 8 and/or add an IE7 meta in order to keep using those IE Quirks - or - we have to add an IE8/edge meta if we want it to ignore their non-standard "quirky Doctype trigger" to start taking advantage of IE8 proper.

The default "emulate=IE8" mode is likely to be more of a site breaker in most conscientious developers cases. Well take my code above as an example, it was ready to go for IE8's shiny new strict mode as I expected that the doctype quirk should be gone in IE8. I didn't want it to use the floats or IE5's box model

This code sample was ready for IE8 to start supporting the table properties, and box-sizing, so I kept the conditional float based, quirky box model CSS only targetting 7 and below. But because by default IE8 is still honoring the comment before Doctype, it's not actually using the table properties or the box-sizing which the whole layout needs. So what about that code exactly, is 'emulating' IE8?

So in this case I'm annoyed because I'm forced to go into the page and update the conditional to include 8 and keep using IE7 mode - or - add a meta 8/100/edge to force IE's definition of strict rendering, either way I'm never done making tweaks for IE because I can then go back later and remove the meta once I think it's been long enough or add the xml file or I'll have to update again sometime in the future to check 9, 10, etc....

As with hacks these changes/metas should only need to be required for back compatibility.. not forward.

PS: great topic, perhaps we need to change the title of this thread or move it to it's own thread

jameshopkins




msg:3951012
 4:48 pm on Jul 12, 2009 (gmt 0)

First off, I suggest we inforce some common terminology here, to prevent further confusion.

  • Doctype Switching - refers to the method of switching between Standards Compliance Mode and Quirks Mode, namely by the inclusion (or not) of a well-formed Doctype.
  • Compatibility View - the current name given to invoking IE7's rendering engine (which includes that bugs specific to that engine) in IE8.
  • Compatibility List - refers to the XML-based 'Compatibility' list - based on telemetry data - that is shared between users of IE8 (who have explicitly opted in to this feature), which governs whether a domain is rendered in Compatibility View.
  • IE8 mode - whether implied or explicitly defined (by the HTTP Header or META delcaration) or not, this renders documents in IE8's most 'standards-compliant' (claimed to be fully CSS2.1 compliant, but isn't) mode.

By default they are rendering the pages in either Quirks or Standards Rendering Mode depending on the version of "IE standards" they have set in the past

I'm not entirely clear what you mean here? By "IE standards", are you referring to IE version targeting or Compatibility View?

Sure enough if I remove the conditional from around the comment it goes into quirks mode in IE8 too (like IE5 mode), i.e. it's 'respecting' the Doctype directive, well the way it used to anyway. Then if I force IE8 mode using the meta tag it goes back into standards (same as my conditional in the code above was doing)

This is one aspect I had no idea of.

However, I guess Microsoft didn't anticipate authors wanting to trigger Quirks Mode, then re-invoking IE8 mode (by specifying the relevant EmulateIE8 value in either the HTTP Header or META declaration) . I strongly believe that Quirks Mode and IE version targeting should be mutually exclusive; that is, version targeting should be rendered useless, if a document is being rendered in Quirks Mode. This would be the most intuitive approach to take since, the inclusion of a well-formed Doctype is neccessary in a document - that doesn't contain a specific IE rendering mode - to trigger Standards Compliance Mode, therefore implicitly triggering IE8 mode. I think really the only compelling argument here is that a document with a malformed or missing Doctype should trigger Quirks Mode regardless of whether an IE rendering mode is specified, to bring it inline with the behavior that other browsers exhibit.

The fact that they allow a comment before a STANDARDs compliant Doctype to even trigger their own little Quirks Mode should no longer be available by default

Agreed; this is a bug. An HTML comment (or XML prolog, in IE6's case) used in a document that has a well-formed doctype, should NOT trigger Quirks Mode. I am unsure as to what you're referring to when you say "...their [IE8's] own little Quirks mode..."; by either omitting a doctype, or placing an HTML comment in certain places, this invokes the cross-browser recognised Quirks mode- the implementation as seen in IE5.

Those who have taken, or now want to take advantage of it for backwards compatability (like hacks) can choose to serve their sites in IE7 Compatibility view for minimal interruption

As explained before, Doctype Switching is an entirely different mechanism to IE's version targeting model (e.g Compatibility View, IE8 mode, Edge mode). Quirks Mode emulates a rendering engine that far precedes the rendering engine of IE7. Of course, we shouldn't expect authors to utilise Quirks Mode when writing new documents, but IE8 still needs to support this mode to ensure backwards compatibility for legacy documents. Compatibility View shouldn't be seen as a model to supercede Quirks Mode.

But now we still have to in there and either update the conditionals to include 8 and/or add an IE7 meta in order to keep using those IE Quirks - or - we have to add an IE8/edge meta if we want it to ignore their non-standard "quirky Doctype trigger" to start taking advantage of IE8 proper.

I don't really understand what you're trying to say here; please elaborate.

if I didn't have time yet to figure out any/all changes a site might require in one go, then I would choose Emulate=IE7 mode (or force compatibility view) until such times as I was confident to make the switch, but then it turns out we SHOULD have some sort of IE8 meta anyway in order to "trim" our sites from users lists if they've already chose to put our sites in compat view themselves.

I'm not sure I understand you here. You're saying you would initially invoke Compatiblity View by the use of either the META declaration or HTTP Header, but you still feel the need to add a version targeting declaration to "'trim' our sites frm user lists if they've already chose to put our sites in compat view themselves". If your sites is already rendered in Compatibility View due to a users own preferences, then there would be no need add a version targeting declaration specifying EmulateIE7.

This [in SuzyUK's initial post] code sample was ready for IE8 to start supporting the table properties, and box-sizing, so I kept the conditional float based, quirky box model CSS only targetting 7 and below. But because by default IE8 is still honoring the comment before Doctype, it's not actually using the table properties or the box-sizing which the whole layout needs. So what about that code exactly, is 'emulating' IE8?

This is correct, since due to IE8's Doctype Switching bug relating to comments preceding the Doctype, IE8 makes no distinction between version operators within Conditional Comments placed in this way. IMHO, I think the code example you demonstrate can be quite unstable, as IE8's handling is highlighting.

The very strictest IE8 mode does indeed take that 'feature' away, forcing standards compliant rendering mode by ignoring IE's quirky triggers

If by "quirky triggers" you're referring to Doctype switching, then no; you can still utilise Doctype switching in IE8's default rendering mode.

Version Targeting in IE8
One thing I didn't ellaborate on in my previous post was version targeting in IE8.

This aspect is something I strongly disagree with, since it discourages the use of future advancements in CSS. If a document is locked to a specific version of a rendering engine, then it rules out the use of new features that weren't implemented in that particular rendering engine. Although voices around the CSS community are discouraging the use of the IE=Edge mode (which invokes the rendering engine version of the latest versions of IE as they are released), on the grounds of regression bugs being introduced in later versions, I would definitely advocate the use of this tag. The bottom line IMHO, is as authors, we should not be expected to lock down a site to one particular version of a rendering engine on the assumption that un-resoverable regression bugs will occur, due to ineffective bug management from Microsoft.

SuzyUK




msg:3951144
 9:49 pm on Jul 12, 2009 (gmt 0)

Not really disputing terminology here as I realize that is half the battle, but unless you're an MS employee/engineer in disguise or it's written down somewhere in authority - I suggest we keep this in real world terms that most are likely to understand, or come across it by. There may be some quite capable of reading complex specs, but perhaps there are others who have no desire to especially where MS in concerned, benefit of the doubt only goes so far ;)

So for the sake of playing devils advocate here..

Doctype Switching - refers to the method of switching between Standards Compliance Mode and Quirks Mode, namely by the inclusion (or not) of a well-formed Doctype.

I know and agree.. however the Comment or XML prolog before the Doctype has nothing to do with actual Doctype's well-formedness. The XML prolog BUG was removed in IE7.. the comment bug should be removed in IE8, by DEFAULT.

It has been removed, but only if you "explicitly" specify the strict IE8 mode by providing an HTTP header, meta IE8/edge/100 tag, xml file, not by default.

To me the default IE8 behaviour should be it's removal, it was a hack it should not be default in IE8. If it really must honor it when emulate=IE8/default mode comes across it, it should not attempt to render the page in IE8 quirks mode, but instead in IE7 compatibility view, after all the "hack" is an IE7 one so it's heir own compatibility I'm on about here.. not any standard that I know of?
Also when I think about it there's no way IE8 could render a 'Quirks Mode' page without resorting to the IE7 engine anyway because it would be unable to incorporate the newer CSS2.1 support along side quirks.

If IE8 had resorted to IE7 mode in the case of my example above then it would have rendered just fine and I could have got mad about all this "having to add meta" later :)

By default they are rendering the pages in either Quirks or Standards Rendering Mode depending on the version of "IE standards" they have set in the past

I'm not entirely clear what you mean here? By "IE standards", are you referring to IE version targeting or Compatibility View?

Neither, If a document is using a "bug" to trigger IE's quirks mode that's equivalent to their own Standard as no other browser uses this trigger nor is it specified anywhere. Using the IE8 default the document as it stands without hiding the trigger or adding an IE8 meta is being rendered in quirks mode, it is "emulating IE8" whatever that means. Whereby hiding the comment trigger quirk invokes standards mode in the default IE8 as does adding the IE8 meta.

It's their quirk they should deal with it properly - when I ask for IE8 by default I expect to get it, at the very least it should go into IE7 compatibility view by default to deal with their own Standard of using that comment as a trigger, especially if that's all they think CSS authors are capable of. (they do seem to continue to underestimate the informed!) IMHO that would make the most sense..

by either omitting a doctype, or placing an HTML comment in certain places, this invokes the cross-browser recognised Quirks mode

I understand that omitting a Doctype or using a certain other ones will trigger quirks x-browser, but the HTML comment? as far as I'm aware that's not a cross-browser recognized standard, only an IE one?

But now we still have to in there and either update the conditionals to include 8 and/or add an IE7 meta in order to keep using those IE Quirks - or - we have to add an IE8/edge meta if we want it to ignore their non-standard "quirky Doctype trigger" to start taking advantage of IE8 proper.

I don't really understand what you're trying to say here; please elaborate.

What's to elaborate, it's simply saying we cannot leave IE8 to default - it's not be trusted (unless you know every single nuance of their Mode spec), there were many warnings out there to this effect before real-world scenarios became tested, and I wondered why, but decided to leave it. (naive trust?) until I found a case to test for myself. This case is perhaps not the best but now I understand.

You're saying you would initially invoke Compatiblity View by the use of either the META declaration or HTTP Header, but you still feel the need to add a version targeting declaration to "'trim' our sites frm user lists if they've already chose to put our sites in compat view themselves". If your sites is already rendered in Compatibility View due to a users own preferences, then there would be no need add a version targeting declaration specifying EmulateIE7.

No I'm saying - IF I as the author decide I want to invoke Emulate IE7 mode, even temporarily, to 'help' any uninformed users who don't know about prefs lists yet, or give myself time to test all scenarios.. then I will, and regardless of my choice, if a user got there before me and added it to their prefs list. I am still going to have to go in at a future date and remove the IE7 meta and add an IE8 meta in order to "refresh/trim" their list, so in essence I'm probably best to add that IE8 meta right from the start in order to help the whole transition. But that's not what we've been led to believe with IE's magnanimous swap of the default behaviour is it?

If by "quirky triggers" you're referring to Doctype switching, then no;

I'm simply referring to IE's quirkiness in accepting the comment as a Doctype switching method. I know I can still put IE8 into quirks using the usual x-browser Quirks Mode triggers, although I'm also still wondering quite why anyone would want to do that?

IMHO, I think the code example you demonstrate can be quite unstable, as IE8's handling is highlighting.

now that I have to chuckle at (in my devils advocate capacity), what exactly is unstable about that example, presuming it was written 2+ years ago, EXCEPT for IE8's "handling" of my Doctype directive. What is wrong with my Doctype directive? Would any truly CSS2.1 compliant browser have a problem with it? - simply put I took IE8 at their word and gave them one of their own bugs (which even you agree is a bug) and they failed to render my perfectly conditionally separated code BY DEFAULT.

So now I think my conditional "hack" around the Bug Comment is actually far more stable than finding the right IE8 rule, I don't want to use the IE Meta's unless I need to for a solid reason, e.g. Compatibility view. If a user decides to put my sites, templates or layouts into compat view.. that's entirely up to them it will be their loss or preference, CSS has only ever been a suggestion anyway. If users then decide to take it out of compat view they will get the enhancements the CSS suggests (2.1 or 3!). All I want is to be able to continue to suggest a document using the best CSS for the job.

I really am an easily pleased person, CSS is a simple language.. IE is making it unnecessarily complicated.

The simple outcome of this, for me anyway, is that I would never ever have dreamed of recommending using Quirks mode up until this point. It was not conducive to the future of CSS but now in the the interests of backwards compatibility it's an option, especially when it comes to box-sizing. So now that the future seems safe backwards compatible quirks mode rendering has its place. If I want to use it I will feed a Quirky Doctype to IE6/7 via their own conditionals rather than trying to let IE8 take it's best guess what I'm doing. Because? - they don't trust their own mistakes and past advice even though they were likely only reaching the design community with that advice, and it's only likely the design community that know about these loopholes, they still think they "know" best as always :(

Us CSS real world authors didn't get this far with CSS by relying on MS's "rules", we've played by their "safety" recommendations for the last 2+ years but now it's nearly time to real world IE8,

all of the above, except my initial example, of course presumes that the CSS/front-end designer also has access to change the HTML.. which sadly in not always the case and is not the CSS ethos, the biggest barrier perhaps?

jameshopkins




msg:3951191
 12:50 am on Jul 13, 2009 (gmt 0)

Doctype Switching - refers to the method of switching between Standards Compliance Mode and Quirks Mode, namely by the inclusion (or not) of a well-formed Doctype.

I know and agree.. however the Comment or XML prolog before the Doctype has nothing to do with actual Doctype's well-formedness. The XML prolog BUG was removed in IE7.. the comment bug should be removed in IE8, by DEFAULT.

My defintion describes the trigger that is common throughout browsers; it isn't there to describe IE's unique behaviour, as this is described later on in my post. I am in no way trying to justify the existance of the Doctype switch Comment bug in IE8; it's a bug and as such, should be removed.

It [the 'comment bug'] has been removed, but only if you "explicitly" specify the strict IE8 mode by providing an HTTP header, meta IE8/edge/100 tag, xml file, not by default.

Yes, this would behaviour match up with what you initially found out, and what I concluded with. As I mentioned in my last post, it appears that if a META or HTTP Header is declared, this champions any recognised (omission of Doctype) or IE-specific (comment before Doctype, etc) Doctype switch trigger.

To me the default IE8 behaviour should be it's removal, it was a hack it should not be default in IE8. If it really must honor it when emulate=IE8/default mode comes across it, it should not attempt to render the page in IE8 quirks mode, but instead in IE7 compatibility view

So you're proposing losing the backwards compatibility aspect for documents that were coded for IE5 (Quirks Mode) by using the IE7 rendering engine when a Doctype is omitted, or a malformed Doctype is used?

Using the IE8 default the document as it stands without hiding the trigger or adding an IE8 meta is being rendered in quirks mode, it is "emulating IE8" whatever that means.]

How did you reach this conclusion of IE8 "emulating IE8"? I've set up a test case with the conditions you describe <link removed, provide code please, you can refer to my code sample for conditions I describe> and it renders in Standards Compliance Mode in IE8 Mode. (if you want to remove my link, fair enough; but it demonstrates my point without having to describing it in much detail).

I understand that omitting a Doctype or using a certain other ones will trigger quirks x-browser, but the HTML comment? as far as I'm aware that's not a cross-browser recognized standard, only an IE one?

This is a bug. There's no logical reason why this behaviour should exist.

What's to elaborate, it's simply saying we cannot leave IE8 to default - it's not be trusted (unless you know every single nuance of their Mode spec), there were many warnings out there to this effect before real-world scenarios became tested, and I wondered why, but decided to leave it. (naive trust?) until I found a case to test for myself. This case is perhaps not the best but now I understand.

Why do you feel you can't "leave IE8 to default"? Are you concerned about IE8's buggy Doctype trigger? Please send me a link to the test case, so I can read further into what you mean.

No I'm saying - IF I as the author decide I want to invoke Emulate IE7 mode, even temporarily, to 'help' any uninformed users who don't know about prefs lists yet, or give myself time to test all scenarios.. then I will, and regardless of my choice, if a user got there before me and added it to their prefs list. I am still going to have to go in at a future date and remove the IE7 meta and add an IE8 meta in order to "refresh/trim" their list, so in essence I'm probably best to add that IE8 meta right from the start in order to help the whole transition

Firstly, it's worth asking yourself why users would choose to view your site in Compatibility View.

One valid reason would be that your site relies on the quirks/spec violations present in IE7, and looks broken in IE8 Mode. If, after a time, the author updates the site with code that is in line with standards and they wish there site to be rendered in IE8/Edge mode, then they would need to go through the process of removing their site from the Compatibility List - the first step (including the HTTP Header or META declaration) in this process will also remove your site from a users local list. The question however remains, why would you want "to add that IE8 meta [presuming IE8 Mode meta] right from the start in order to help the whole transition", if you initially invoke Compatibility View to give yourslef time to "test all scenarios".

I know I can still put IE8 into quirks using the usual x-browser Quirks Mode triggers, although I'm also still wondering quite why anyone would want to do that?

Retaining backwards compatibility among documents which relied on non-standard behaviour. Of course no authors these days should be invoking Quirks Mode.

what exactly is unstable about that example, presuming it was written 2+ years ago, EXCEPT for IE8's "handling" of my Doctype directive

OK, this is something new to me, and thanks for highlighting it in this thread. An HTML Conditional Comment (complete with version operator) which precedes a well-formed Doctype, does NOT induce Quirks Mode. Whereas, a standard HTML comment preceding a well-formed Doctype does induce Quirks Mode. I didn't think IE8 would treat version-targeted comments any different to regular ones. These findings have been noted.

Maybe I worded my comments on your example a bit inappropriately; what I was trying to get across was my concern at triggering Quirks Mode in only IE6 and IE7 (I guess to utilise the broken box model), and dealing with Quirks issues that arise.

Apologies about my incorrect CC assumption. If nothing else, this thread is providing some interesting discussion :)

[edited by: SuzyUK at 11:48 pm (utc) on July 15, 2009]
[edit reason] personal link removed, please provide code thanks [/edit]

swa66




msg:3951196
 1:11 am on Jul 13, 2009 (gmt 0)

Firstly, it's worth asking yourself why users would choose to view your site in Compatibility View.

Let's not forget Microsoft has a list of sites they default in IE7 mode.

[msdn.microsoft.com...]

The current list can be accessed from within IE8:
res://iecompat.dll/iecompatdata.xml - It's not a web address, it's something internal

The list now a.o. includes ccTLD google versions and when you surf to them with IE8 it'll render it in IE7 mode and the UI will remove the button to see the page in IE8 mode ...

I'm not sure why they think google needs IE7 mode. Honestly: the sites work just fine in chrome, safari, firefox and the like. But I guess it's part of the war.

jameshopkins




msg:3953379
 11:18 pm on Jul 15, 2009 (gmt 0)

Let's not forget Microsoft has a list of sites they default in IE7 mode.

Indeed; it's been mentioned several times previously in this post :)

I'm not sure why they think google needs IE7 mode. Honestly: the sites work just fine in chrome, safari, firefox and the like.

When invoked, Compatibility View applies to the entire domain, so that includes Mail, Maps, etc... And I'm not sure who you're referring to when you say "they". The Compatibility View list is made of telemetry data compiled by sources such as, recording Compatibility View experiences of users (who have opted in to this feature), customer-filed bugs, and Microsofts own site testing. So it's not just Microsoft who play a part in which domains end up on the list.

SuzyUK




msg:3953413
 12:36 am on Jul 16, 2009 (gmt 0)

How did you reach this conclusion of IE8 "emulating IE8"?

like I've been trying to ask, is it emulate or is it IE8 proper? that's what I want to know : So simply remove the wrapper IE CC from my original code example,leaving the <!-- comment --> it's hiding in place (i.e. let IE8 see the quirks triggering comment) - then, before you test - You tell me which of the first three you think best suits my doctype and how IE8 should follow it (your test case only tested a Standards compliant doctype which I would've expected to, and did, fit in with #2)

Then test and do do tell me which statement you think is being matched more closely:

  • 1. EmulateIE8 mode is similar to EmulateIE7 mode; Internet Explorer uses the <!DOCTYPE> directive to determine how to render content;
  • 2. standards mode directives are displayed in Internet Explorer 8 Standards mode.
  • 3. Quirks mode directives are displayed in IE5 mode.

the above is a literal quote from IE (separated by me) from earlier in the discussion,
and do remember this bit too:
Emulate IE8 mode tells Internet Explorer to use the <!DOCTYPE> directive to determine how to render content. Standards mode directives are displayed in Internet Explorer 8 standards mode and quirks mode directives are displayed in IE5 mode. Unlike IE8 mode, Emulate IE8 mode respects the <!DOCTYPE> directive.

(OH and IE7 quirks = IE5 in my books as far as the MS terminology goes.. if I'm using quirks for simply box-sizing or to ignore table cell propeties.. then I expect that IE7 or 6 or 5 will act the same way.. I suspect that MS is trying to enforce the same thing by simply ignoring IE6 in their documentation, heh.. it would be easy if we could do that too ;))

simonuk




msg:3953663
 12:58 pm on Jul 16, 2009 (gmt 0)

I used to enjoy coming to these forums...it gives me a headache now ;-)

jameshopkins




msg:3954467
 4:28 pm on Jul 17, 2009 (gmt 0)

So simply remove the wrapper IE CC from my original code example,leaving the <!-- comment --> it's hiding in place (i.e. let IE8 see the quirks triggering comment) - then, before you test - You tell me which of the first three you think best suits my doctype and how IE8 should follow it

As you've removed the IE Conditional Comment operator - which from this thread, we've ascertained does not invoke Quirks Mode if a complete IE Conditional Comment precedes the Doctype - Quirks Mode will be invoked. An interesting observation is that in this instance, Standards Compliance Mode cannot be subsequently set by declaring either 'IE8 Mode' or EmulateIE8 Mode', in an effort to try and align Document Modes cross browser.

IMHO, the terminology adopted by Microsoft to describe the different rendering modes is appallingly unintuitive. Firstly, we aren't emulating anything here (or at least we shouldn't be); the only difference between 'IE* Mode' and 'Emulate IE* Mode' is a dependance on a well-formed Doctype, which could be seen as an extension to the feature, certainly not an emulation. Secondly, the term 'Emulate IE8 Mode' is very misleading, as it implies that IE8 can emulate itself; this could be even more confusing for users of Beta 1 who were familiar with the term 'Emulate IE7' (which has now become Compatibility View), which correctly refers to triggering IE7's rendering engine. Thirdly, the term 'Emulate' in this context does not make sense, as it gives no clue to the distinctions between Modes.

SuzyUK




msg:3954616
 8:37 pm on Jul 17, 2009 (gmt 0)

@simon = sorry ;) but do feel free to help here!

James I agree the this whole thing is not intuitive. The Emulate=IE8 is the dark horse in all this. I so don't understand why they've left the <!-- comment --> bug in there in the first place, but I found a 2008 reply to a report of this "bug" where the IE team are not "fixing" until maybe a future version :(

I think perhaps 'Emulate' is their get out clause until that happens, but what they can do with that in future, I'm not sure.

Anyway I also found this (1st and 2nd) table [blogs.msdn.com] on a MS blog which helps spell out the issue (well a little better than IE's double speak) and from those, yes I think it would be safe to say the the default behaviour is indeed Emulate IE8

What is Emulate IE8?
My thoughts only...
My Doctype is quirks in their eyes thanks to the bug, so they are rendering as IE5 as per the emulate IE8 rules, BUT they are also honoring the conditional CSS which is dictating that only versions less than 8 get the floats code (as opposed to the tables). So in that respect it is Emulating IE8 by honoring the IE8 conditonal CSS, i.e. it is not feeding the float code to my document - but what the heck use is that when obviously a quirks page (IE5 in their terms) is obviously going to need LT IE8 conditional CSS, presuming the author has been dealing with, or suffering the consequences of, IE5/6/7 up until now.

Hence I think the more obvious solution, if they don't trust us, would be for them to trip their own "quirks" mode to IE7 Compat, as anyone (well most) using Quirks would not be taking advantage of the IE7 "improvements" let alone IE8 conditional CSS anyway..

An interesting observation is that in this instance, Standards Compliance Mode cannot be subsequently set by declaring either 'IE8 Mode' or EmulateIE8 Mode'

It does set Standards Compliance mode if you explicitly put in the IE8 meta, which led me to thinking about this "standards default" in the first place, that and if you put in the "Emulate IE" meta there is no change the rendering.

my 2nd peeve is the fact that originally they were going to render all pages in IE7 Compat view and it was going to be up to us authors to have to put in the IE8 meta (which is the bit that as CSS author/developer does not always have control over!).. and what I'm saying now is that either way we could very land up having to add that IE meta anyway. IE 'standards' are, again not always what they seem :(

swa66




msg:3954706
 12:46 am on Jul 18, 2009 (gmt 0)

I'm with simonuk: my head hurts :)

Seriously: this is way too complicated. Somewhere at Microsoft there must somebody laughing his head off about this. They asked for standards, look what it yielded them, we're soooo funny.

Just imagine if we had to put up with this silliness from every browser out there.

I still feel it's simplest to treat IE8 as if it were somewhat of a standards complaint browser, with a serious lack of CSS3 ready features that will haunt us in the future.

As long as your site isn't listed in their "automatic compatibility" list and you don't add anything specific and keep code that keeps IE6 out of quirks (full doctype with nothing in front of it), you should always get IE8's most standard compliant mode ? Right ?

Or did my headache interfere with getting it right ?

jameshopkins




msg:3955907
 5:01 pm on Jul 20, 2009 (gmt 0)

I so don't understand why they've left the <!-- comment --> bug in there in the first place, but I found a 2008 reply to a report of this "bug" where the IE team are not "fixing" until maybe a future version

I guess it wasn't high on their priority list. Which ticket/reply were you referring to? Gerard Talbots bug report (which is the one in Connect) only refers to the XML prolog issue, as far as I remember [note to self: must update that ticket]

Anyway I also found this (1st and 2nd) table on a MS blog which helps spell out the issue

Thanks for the link - that's bookmarked.

Hence I think the more obvious solution, if they don't trust us, would be for them to trip their own "quirks" mode to IE7 Compat, as anyone (well most) using Quirks would not be taking advantage of the IE7 "improvements" let alone IE8 conditional CSS anyway..

But we still need to include support for documents that are coded based on IE5s rendering.

An interesting observation is that in this instance, Standards Compliance Mode cannot be subsequently set by declaring either 'IE8 Mode' or EmulateIE8 Mode'

It does set Standards Compliance mode if you explicitly put in the IE8 meta, which led me to thinking about this "standards default" in the first place, that and if you put in the "Emulate IE" meta there is no change the rendering.

Thanks for spotting this mistake of mine; not sure how I came up with that conclusion :) So yes, adding the META declaration with a value of 'IE8 Mode' will set Standards Compliance Mode.

my 2nd peeve is the fact that originally they were going to render all pages in IE7 Compat view and it was going to be up to us authors to have to put in the IE8 meta (which is the bit that as CSS author/developer does not always have control over!).. and what I'm saying now is that either way we could very land up having to add that IE meta anyway. IE 'standards' are, again not always what they seem.

The majority of authors won't have to even worry about this issue. If however there are noticeable rendering issues in Emulate IE8 mode when rendering a site, then this 'compatibility' aspect of IE8 is something that those authors need to explore.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved