Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
Alex Robinson wrote: Now, as an aside and not being particularly expert on quirks mode rendering, are there any specific differences (other than the ones just discussed) that anyone is aware of between IE6 quirks mode and IE7 quirks mode? (I'm fully aware of their being many standards mode issues ;) The few cases that I'm aware of are all cases where IE7 in standard mode has improved behavior, and in quirks mode it shows some mixed behavior, not exactly equal to IE6 quirks. One example is the box expansion caused by italics. In IE7 standards mode some cases are fixed. In IE7 quirks they are not fixed (I guess intentionally), but they react to the various display values differently than IE6 quirks (so limiting the set of workarounds good for both.) I have a (very unfinished) page showing some of these differences [1]. Bruno [1] http://brunildo.org/test/IE6_7_quirks.html -- Bruno Fassino http://www.brunildo.org/test __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
I've seen a couple of other cases (not related to parsing/selectors problems but to rendering) where IE8 quirks is equal to IE7 quirks when this differs from IE6 quirks. Also, I just noticed (again, this may be old news by now) that fieldsets and input buttons (and presumably all form elements) are displayed in the manner of IE7 when X-UA is IE=5. So, to recap IE=5 - IE7's quirks mode (regardless of doctype) IE=7 - IE7's standards mode (Standards or Quirks mode with doctype and no url) IE7's standards-ish mode ignoring *+html (Quirks mode without doctype) IE=8 - IE8 native (Standards or Quirks mode with doctype and no url) IE8 native-ish mode ignoring *+html (Quirks mode without doctype) Pretty much then what Microsoft have said then, but perhaps this would have been easier to digest, if it was IE=quirks instead of IE=5 and that it had been explicitly spelt out that it was IE7's quirks mode that was meant. Now, as an aside and not being particularly expert on quirks mode rendering, are there any specific differences (other than the ones just discussed) that anyone is aware of between IE6 quirks mode and IE7 quirks mode? (I'm fully aware of their being many standards mode issues ;) __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
On Sun, Mar 9, 2008 at 2:55 AM, Alan Gresley wrote: What about using the ID class selector bug or the last class bug. http://www.brettschultz.com/ie6_exhibit_a.html IE8 in IE5 quirks mode is showing the last test Aqua. and first and second test red. IE6 will show red, red, transparent. The page so happens to have no doctype (handy). Would this only happen if it was IE7 quirks? Yes, it seems that the last test in that page is one of the few cases where IE7 quirks mode differs from IE6 quirks mode. And IE8 quirks mode follows IE7, not IE6. I've seen a couple of other cases (not related to parsing/selectors problems but to rendering) where IE8 quirks is equal to IE7 quirks when this differs from IE6 quirks. Bruno -- Bruno Fassino http://www.brunildo.org/test __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
You now have your quirks mode documents with no doctype. If I put in a quirks mode doctype (HTML 4.01 Transitional, no url) then IE8 behavior in those two cases changes. It sees the *+html, as with a standard doctype, like the X-UA IE=8 or 7 overrode the quirks mode of the document. This is more expected. Holey kamoley! Good catch! I've added a second quirks mode to both the iframe demos and the hack filters. As you said, the HTML4 without a URL provokes the expected quirks behaviour with regard to * html. http://local.fu2k.org/alex/css/cssjunk/ie8/xua http://local.fu2k.org/alex/css/cssjunk/ie8/tests/ (yet again) So it seems to be the absence of doctype together with X-UA IE=8 to create some strange effects... Oh yeah. In fact it seems the absence of a doctype creates a different kind of quirks mode to the presence of a quirks mode inducing one... Anyhow Alan's mention of the ID class selector bug and last class bug made me remember running into those very same bugs back in 2003, when I called them runtogetherselectors http://archivist.incutio.com/viewlist/css-discuss/19985 Little did I think that one day they would come in useful as archaeological tools! I've added Fake Class Real Class, Fake Id Real Id, Real Id Fake Class to the test. (For want of better names - if these already have established names, I'll update accordingly). I've also added something I've called Double Id Class which I've never seen before (source order of multiple classes and their styel declarations both crucial). As with the Real Id Fake Class, it also reveals that IE=5 quirks mode is actually closer to IE7 than IE6. So these cases basically confirm what you and Alan have noted about http://www.brettschultz.com/ie6_exhibit_a.html Right, that's it. I must walk away form this now ;) __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
Alex Robinson wrote: I've added a second quirks mode to both the iframe demos and the hack filters. As you said, the HTML4 without a URL provokes the expected quirks behaviour with regard to * html. http://local.fu2k.org/alex/css/cssjunk/ie8/xua http://local.fu2k.org/alex/css/cssjunk/ie8/tests/ (yet again) Seems be off-line, damm... Nope may this will what we want. http://www.fu2k.org/alex/css/cssjunk/ie8/xua http://www.fu2k.org/alex/css/cssjunk/ie8/tests/ So it seems to be the absence of doctype together with X-UA IE=8 to create some strange effects... Oh yeah. In fact it seems the absence of a doctype creates a different kind of quirks mode to the presence of a quirks mode inducing one... I couldn't take it anymore so I ran some test. From my test I have concluded that there are there modes in IE8: 1. IE8 Standard mode 1. IE7 Strict mode 1. IE6 Mystery mode There is no true quirks modes that changes the box model in how you would expect. IE7 Strict mode is the same as IE7 (almost) standard mode. What they claimed is IE5 quirks mode is just nonsense. This is some mode quite like IE6 in (almost) standard mode. I based this all on my own test. To test doing the following. 1. Close any instances of IE8 2. Reload and IE8 and load this page. http://css-class.com/test/index-quirks-control.htm Whichever compatible test you select they are all the same. All three mode (1., 2, and 3) are the same in there appearance. Notice how none of these pages has developed a horizontal scroll bar. In the real IE6 all test look the same (similar IE6 Mystery mode) but it's different from what is claim as IE5 quirks mode, notice how there is a horizontal scroll bar. In the real IE5 all test look the same but horizontal scroll bar is larger and the honor roll has moved further right. This test is important. http://www.fu2k.org/alex/css/cssjunk/ie8/xua-ie5 Instead of having a true quirks mode with old box model, have the IE team somehow created a new mode that calculates a bazaar box model??? This is so wrong and supports what Anne van Kesteren has said. http://annevankesteren.nl/2008/03/ie8-bad He basically says that no other browser will show a page in super standard mode without a doctype, but you can do this in IE8 with IE=8. Anne's last comment sums it up. http://annevankesteren.nl/2008/03/ie8-bad#comment-6499 All I want is a stand alone IE8 in super duper standard mode. We now have to support: 1. The real IE5 (optional) 2. The real IE6 3. The real IE7 and one of the following. 4a. IE8 Standard mode 4b. IE7 Strict mode 4c. IE6 Mystery mode That at least three versions to support. I glad I am just serving up standard content. How can developers cope with working on a site in quirks mode. I believe the toggle will eventually be the switch that an Intranet admin would use to select quirks mode and old box model. But I can't see this working very well. The only thing that seems to be true is IE7 Strict mode equal the real IE7. I will leave this alone now, my head is spinning :-) Right, that's it. I must walk away form this now ;) Yes it does get crazy. I call it Meta Mode Madness! Gorge, just wait for a stand alone version to download (it will be cheaper on bandwidth anyway). Once you perform the IE=mystery test or toggle there no return from the madness. Alan http://css-class.com/test/ __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
Alan Gresley wrote: http://annevankesteren.nl/2008/03/ie8-bad#comment-6499 All I want is a stand alone IE8 in super duper standard mode. We now have to support: 1. The real IE5 (optional) 2. The real IE6 3. The real IE7 and one of the following. 4a. IE8 Standard mode 4b. IE7 Strict mode 4c. IE6 Mystery mode The above may create problems for other browser-makers, unless they do as they've said they'll do - ignore the whole version targeting issue and improve standard-support while keeping _one_ Quirks mode for limited backward-compatibility. Ignoring it sounds like the most, if not only, sane approach. For us designers it's a matter of choice, and I personally will only have to support: 1: IE5.x (ever so slightly, or a bit more if I get well paid for it). 2: IE6 (Quirks mode forever, which secures 99% support of IE5 without additional efforts). 3: IE7 Standard mode (or whatever they call it). 4: IE8-final Standard (no meta) mode. The above doesn't affect my present strategy at all, and IE8 won't add all that much more work than any other version-upgrade of any browser. Either I've been very lucky, or I've just chosen a good strategy to begin with. Either way - it'll work. Yes it does get crazy. I call it Meta Mode Madness! Rightly so, so - apart from giving the IE-team some feedback for those betas so they can improve things a bit, applying some damage-control when IE8-final is out is probably better than trying to make sense of the madness. Gorge, just wait for a stand alone version to download (it will be cheaper on bandwidth anyway). Once you perform the IE=mystery test or toggle there no return from the madness. I'll call in the damage-control team[1] when the time is right - when IE8-final is isolated on its own workstation in my local network, and will otherwise stay out of the madness and just make sure the more sane browsers get what they deserve - the best. In the mean time I'll check here... http://www.howtocreate.co.uk/ie8.html ...to see what progress/regress is made. Less noise on that site :-) regards Georg [1] http://www.gunlaug.no/contents/molly_1_15.html -- http://www.gunlaug.no __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
Gunlaug Sørtun wrote: Alan Gresley wrote: http://annevankesteren.nl/2008/03/ie8-bad#comment-6499 All I want is a stand alone IE8 in super duper standard mode. We now have to support: 1. The real IE5 (optional) 2. The real IE6 3. The real IE7 and one of the following. 4a. IE8 Standard mode 4b. IE7 Strict mode 4c. IE6 Mystery mode The above may create problems for other browser-makers, unless they do as they've said they'll do - ignore the whole version targeting issue and improve standard-support while keeping _one_ Quirks mode for limited backward-compatibility. Ignoring it sounds like the most, if not only, sane approach. Yes I agree, unless your in some dire need to have IE8 in any other mode just feed IE8 your normal style sheet. Just ignore the whole Meta Mode approach all together. The more web developers who code for the standards, the more the web will move in the right direction - forwards. For us designers it's a matter of choice, and I personally will only have to support: 1: IE5.x (ever so slightly, or a bit more if I get well paid for it). 2: IE6 (Quirks mode forever, which secures 99% support of IE5 without additional efforts). 3: IE7 Standard mode (or whatever they call it). 4: IE8-final Standard (no meta) mode. The above doesn't affect my present strategy at all, and IE8 won't add all that much more work than any other version-upgrade of any browser. Either I've been very lucky, or I've just chosen a good strategy to begin with. Either way - it'll work. This made me think about your site. I know my main site has a mysterious gap present and my test pages are really broken in IE8. I though I would see how your code coped. I expected it to cope well. Well I was in for one big surprise as I only had to open your home page (175kb download). http://css-class.com/images/gunlang.png You wouldn't have used display:table any where perhaps? I approach coding for the various IE versions the same as you. Sending IE6 into quirks mode help with IE5. Then there IE7. With IE8 I am seeing bugs that require floats to be non floated. Elements floated to be absolutely positioned (for correct stack). I guess this is all normal since we are dealing with a new layout engine. Most site will cope very well in IE8, it's only some sites (yours and mine for example) that are some what broken. The CSS issues that courses such breakage must be fixed before IE is released to the general public. Yes it does get crazy. I call it Meta Mode Madness! Rightly so, so - apart from giving the IE-team some feedback for those betas so they can improve things a bit, applying some damage-control when IE8-final is out is probably better than trying to make sense of the madness. I want a stand alone version of IE8. I can see the IE team spending to much time fixing up all these modes where they should really be focusing on just the real IE8 and better standards support. The madness is the backwards compatibility which I will not be testing any further. I myself will just stick with the real IE8 and maybe use IE7 mode occasionally to check for IE7. I'll call in the damage-control team[1] when the time is right - when IE8-final is isolated on its own workstation in my local network, and will otherwise stay out of the madness and just make sure the more sane browsers get what they deserve - the best. [...] regards Georg [1] http://www.gunlaug.no/contents/molly_1_15.html I wish I had a local network. I have just one laptop here, but I to intend on setting a local network in the future. I have added a new page that I will track issues with IE8 which I find. It can be found here. http://css-class.com/test/bugs/ie/ie-bugs.htm Alan http://css-class.com/ __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
Alan Gresley wrote: http://css-class.com/images/gunlang.png You wouldn't have used display:table any where perhaps? Yes, and I wouldn't dream of making changes until IE8 is fixed and stable. It's the browser that's broken, not the design. If they are serious about CSS 2.1 support, then it won't do much good to fix well-working CSS 2.1 based designs for their at present very broken beta. If it stays that broken then I'll probably throw it back to Quirks mode (without using the meta-switch). I approach coding for the various IE versions the same as you. Sending IE6 into quirks mode help with IE5. Then there IE7. With IE8 I am seeing bugs that require floats to be non floated. Elements floated to be absolutely positioned (for correct stack). I guess this is all normal since we are dealing with a new layout engine. Not normal at all - except for alpha-versions for group/internal testing. Most site will cope very well in IE8, it's only some sites (yours and mine for example) that are some what broken. The CSS issues that courses such breakage must be fixed before IE is released to the general public. Let's hope so. I wish I had a local network. I have just one laptop here, but I to intend on setting a local network in the future. 4 win-boxes and an iMac, and 10 screens, sure helps while debugging and testing (especially since I have a slow net-connection that simply can't be improved until later this year at best). Having a reasonably fast box as main, and a few cheap or reclaimed ones around in a simple network, will work well for most. Almost any old box is good enough up to winXP as long as it has backbone and memory enough to run IE/win. Needs loads of memory if you want to make use of multi-screen and side-by-side comparison across browser-land without having to switch. If you buy new boxes you may as well go for 9.5/19 industry models or something similarly slim/small, and create a compact work-space. I have added a new page that I will track issues with IE8 which I find. It can be found here. http://css-class.com/test/bugs/ie/ie-bugs.htm Bookmarked. regards Georg -- http://www.gunlaug.no __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
In IE6 all lines are of equal length. So this would mean that IE8 is emulating the quirks modes different to how IE6 and IE7 handle quirks mode. Is this correct? Nope. Or rather I don't think so. I think your original suggestion was correct. ie. IE=5 actually causes IE8 to emulate IE6 in quirks mode. End of story. My error was to use documents in standards mode as the reference point. I have now updated http://www.fu2k.org/alex/css/cssjunk/ie8/xua accordingly so that it is possible to see the effect of the X-UA switch on both standards and quirks mode documents. Along with screengrabs of the observed behaviour. If it all gets too much, you can switch off the bits you don't want to see (suggestions for better text in the legends welcome!) Now, we can see that IE8's rendering is entirely in line with IE6's quirks mode rendering. We can also see that it is definitely not rendering along the lines of IE5 (either 5.01 or 5.5) This got me wondering if IE8 was actually emulating IE6 or IE7 in quirks mode, so I threw together a test suite that pulls together all the hacks/filters that have been used to target various versions of IE and see what happens when targeting different X-UAs. http://www.fu2k.org/alex/css/cssjunk/ie8/tests IE=5 --- The results show that IE8 is definitely using IE6 when forced into quirks mode by IE=5. All the results tally with IE6 behaviour and we can rule out IE7 behaviour because IE8 in IE=5 mode applies the Star HTML selector selector (* html) but not the Star plus HTML selector (*+html). In fact the only slight niggle where IE8 differs from IE6 is that IE6 only applies the Property + Whitespace + Empty Comment filter to documents authored in quirks mode, but IE8 applies it to standards mode ones too. But, that is what one would expect really, since the IE=5 is an explicit Give me quirks switch. IE=7 --- There is nothing noteworthy to mention about IE7 emulation. It all appears to be consistent. IE=8 --- The only hack / target combination which does not jibe, is the fact the *+html hack also gets applied by IE8 when targeted as IE=8. To repeat *+html targets IE8[0]. Since this only previously targeted IE7, this selector in conjunction with a new selector that IE8 understands but IE7 does not, gives us a current easy way to target IE8. Obviously this is not recommended and hopefully this parsing error will be fixed before a final release and relax Final rumination If you made the foolish mistake of actually choosing to use standards mode [1] and make IE6 work in it, then you are not able to rely on an X-UA fix. You are doomed to keep fixing each latest variation of CSS support that MS foists upon us, regardless of the glib assertions that all one needs so is set the X-UA header and you're all done. sarcasm_as_big_as_the_ritzSo yeah, the business case of using standards has been truly proved I think. /sarcasm_as_big_as_the_ritz [0] I haven't seen it mentioned elsewhere, but I'm sure somebody has already discovered it - probably even on this very list which I skimmed merrily over [1] That would be me - I've never once authored a quirks mode document since the distinction existed __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
On Sat, Mar 8, 2008 at 8:54 PM, Alex Robinson [EMAIL PROTECTED] wrote: ie. IE=5 actually causes IE8 to emulate IE6 in quirks mode. End of story. My error was to use documents in standards mode as the reference point. I have now updated http://www.fu2k.org/alex/css/cssjunk/ie8/xua accordingly so that it is possible to see the effect of the X-UA switch on both standards and quirks mode documents. Along with screengrabs of the observed behaviour. If it all gets too much, you can switch off the bits you don't want to see (suggestions for better text in the legends welcome!) I mostly agree, but not on the Rendered by IE 7 and quirks combinations. Your documents now have an xml declaration at the beginning which puts IE6 in quirks mode, but NOT IE7. The Rendered by IE 7 row should be exactly as the Rendered by IE 6 row. Bruno -- Bruno Fassino http://www.brunildo.org/test __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
Alex Robinson wrote: IE=8 --- The only hack / target combination which does not jibe, is the fact the *+html hack also gets applied by IE8 when targeted as IE=8. To repeat *+html targets IE8[0]. Since this only previously targeted IE7, this selector in conjunction with a new selector that IE8 understands but IE7 does not, gives us a current easy way to target IE8. Obviously this is not recommended and hopefully this parsing error will be fixed before a final release and relax [0] I haven't seen it mentioned elsewhere, but I'm sure somebody has already discovered it - probably even on this very list which I skimmed merrily over I guess you have not seen my activity elsewhere. http://groups.google.com/group/alt.html/browse_thread/thread/47e63edf618e75c3 What the IE team did that night made me very suspicious (see my reply 6 down). The page in question is. http://css-class.com/test/css/selectors/ie7hacktargetingopera.htm So I did some reverse testing of IE8. http://css-class.com/cssscript/images.css By the 13 of February I had the results (IE8 applied *+html and div+*+div) so that gave me advance warning to prepare my test. http://css-class.com/test/ That frantic rush to support that better browser named IE/Mac wasn't for no good reason. :-) The other testing of IE8 involved if it supported any new selectors which it doesn't. So I see know way to hack for IE8 without also targeting IE7 (or visa versa), unless someone uses my approach in targeting IE8. /*\*//*/ @import url(test-ie8.css); @import(test-ie.css); /* For IE/Mac */ @import test-ie; /* For IE/Win */ Anyway no hacks should be needed for IE8 and you are correct, IE8 will drop support for *+html and div+*+div in a later beta since they breaks support for sibling selectors and first-child. http://lists.w3.org/Archives/Public/www-style/2008Mar/0049.html Alan http://css-class.com/ __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
I mostly agree, but not on the Rendered by IE 7 and quirks combinations. Your documents now have an xml declaration at the beginning which puts IE6 in quirks mode, but NOT IE7. The Rendered by IE 7 row should be exactly as the Rendered by IE 6 row. The screengrabs I'm using are exactly how IE7 (a real version, not IE8 emulation or a standalone) renders for me. Note that even without the *+html declaration in there, IE6 should see the * html, and IE7 should not. There is no way that the rows could ever be the same. Ah, I see what you mean. The way I have made it go into quirks mode is not actually making IE7 go into quirks mode. My lazy bad. I'll change it so it actually uses a quirks-causing doctype. Done. You're right about the lengths, but IE7's background colour alternates from mode to mode. So not quite exactly the same as the IE6 row. Thanks for picking that up. I was wondering why IE7 wasn't picking up * html in quirks mode and was thinking that I must have either just hallucinated that I'd seen that behaviour before or that some other congruence of bad voodoo had caused it... ;) And obviously, the IE=7 and IE=8 tests for quirks mode were subtly wrong in IE8 too. But that's now fixed. I'll have to redo the hack tests for IE7 and IE8 in quirks mode too now... __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
On Sat, Mar 8, 2008 at 10:22 PM, Alex Robinson [EMAIL PROTECTED] wrote: Ah, I see what you mean. The way I have made it go into quirks mode is not actually making IE7 go into quirks mode. My lazy bad. I'll change it so it actually uses a quirks-causing doctype. Done. You're right about the lengths, but IE7's background colour alternates from mode to mode. So not quite exactly the same as the IE6 row. Yes, correct! When I wrote exactly the same I really meant in the quirks cases. I told I agreed with you on the other ones :-) Now I agree on all cases. At this point I think it's hard to say if with X_UA IE=5IE8 is emulating IE7 quirks or IE6 quirks, simply because the two are hardly distinguishable (I guess is more IE7 than IE6.) Bruno -- Bruno Fassino http://www.brunildo.org/test __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
At this point I think it's hard to say if with X_UA IE=5IE8 is emulating IE7 quirks or IE6 quirks, simply because the two are hardly distinguishable (I guess is more IE7 than IE6.) Yes, my previous claim that we know it's IE6 was founded on the assumption that I was serving quirks mode documents when, as any fule now knows, I wasn't :( The parsing errors appear to be the same. Evidence for which engine is really being used will have to come from elsewhere. Something that shows Moving on. I've now updated the tests. As I guessed would be the case, the tests all stay the same except for the two star html hacks. Now things get somewhat interesting. http://local.fu2k.org/alex/css/cssjunk/ie8/tests/ (again) IE8 is now exactly the same as IE6 when X-UA is IE=5. When X-UA is IE=7 or 8 and the doc is in quirks mode, then things go slightly awry. To recap, IE7 applies *+html in standards mode and ignores * html. In quirks mode, the situation is reversed. IE8 in standards mode matches IE7's standards behaviour (for both IE=7 and IE=8). But in quirks mode, IE8 ignores both * html and * + html (again for both IE=7 and IE=8). If declaring IE=7 or IE=8 was enough to force IE8 into the respective standards modes, the star+html should be applied. But something is obviously going on that is allowing the quirkiness to squash the *+html but not enough to bring the * html back into play. How peculiar is that? Disclaimer - yes, remember kids the use of * html (and I would guess *+html) have long been discouraged by Microsoft and if you want to do anything other than play in the conditional comment sandpit you get everything you deserve... Alternatively, you could draw the conclusion that * html is safe as houses for targeting IE6 and under in standards mode (with or without an X-UA) and IE7 and under in quirks mode (without an X-UA). __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
On Sun, Mar 9, 2008 at 12:18 AM, Alex Robinson wrote: When X-UA is IE=7 or 8 and the doc is in quirks mode, then things go slightly awry. [...] But in quirks mode, IE8 ignores both * html and * + html (again for both IE=7 and IE=8). You now have your quirks mode documents with no doctype. If I put in a quirks mode doctype (HTML 4.01 Transitional, no url) then IE8 behavior in those two cases changes. It sees the *+html, as with a standard doctype, like the X-UA IE=8 or 7 overrode the quirks mode of the document. This is more expected. So it seems to be the absence of doctype together with X-UA IE=8 to create some strange effects... Well, it's time to say thank you Alex for those useful and interesting test pages! Best, Bruno -- Bruno Fassino http://www.brunildo.org/test __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] X-UA-Compatible - Discrepancies between targeted behaviour in IE8 resolved
Bruno Fassino wrote: On Sat, Mar 8, 2008 at 10:22 PM, Alex Robinson wrote: Ah, I see what you mean. The way I have made it go into quirks mode is not actually making IE7 go into quirks mode. My lazy bad. I'll change it so it actually uses a quirks-causing doctype. Done. You're right about the lengths, but IE7's background colour alternates from mode to mode. So not quite exactly the same as the IE6 row. Yes, correct! When I wrote exactly the same I really meant in the quirks cases. I told I agreed with you on the other ones :-) Now I agree on all cases. At this point I think it's hard to say if with X_UA IE=5IE8 is emulating IE7 quirks or IE6 quirks, simply because the two are hardly distinguishable (I guess is more IE7 than IE6.) Bruno What about using the ID class selector bug or the last class bug. http://www.brettschultz.com/ie6_exhibit_a.html IE8 in IE5 quirks mode is showing the last test Aqua. and first and second test red. IE8 in IE7 strict mode is showing the last test Aqua. and first test green and second test red. IE6 will show red, red, transparent. The page so happens to have no doctype (handy). Would this only happen if it was IE7 quirks? I not sure really if this would work. This whole mystery mode thing confuses me. :-) Alan http://css-class.com/ __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
