Bruno Fassino wrote: > On Tue, Mar 9, 2010 at 9:39 AM, Alan Gresley <[email protected]> wrote: >> Bruno Fassino wrote: >>> On Sun, Mar 7, 2010 at 5:47 PM, Alan Gresley <[email protected]> wrote: >>>> It appears that MS has hacked in bidirection (somewhat improved over >>>> IE7) by the use of *hasLayout*. >>>> >>>> <http://css-class.com/test/bugs/ie/ie8-haslayout-bidi.htm> >>> Yes, I see the problem, very interesting! >>> >>> I just would say that "direction" sometimes makes a block a >>> formatting context root (this is not necessarily related to hasLayout, >>> which seems to have no more rendering effects in IE8, even if it still >>> exists just as a dom / javascript property). >> >> Hello Bruno. If this is not hasLayout then why does IE8 behave like IE7 for >> particular bugs when hasLayout (IE7- understanding) has been triggered? >> >> IE8 with IE7 compatibility mode does not show the peekaboo bug or the >> escaping float bug but it does show rendering bands. >> >> <http://css-class.com/test/bugs/ie/strangepeekaboobug.htm> >> > [...] >> Since using hasLayout was IE7- way of generating a block formatting context >> than I see no other option than to declare that this is hasLayout in IE8. >> >> I would say that this test cases of yours would be affected. >> >> <http://www.brunildo.org/test/IEMarginPadding.html> >> >> Here a copy of another of your test cases with dir="rtl" causing IE8 to >> render as IE7. >> >> <http://css-class.com/test/temp/bruno-IEWflm.htm> > > > Alan, > > I agree perfectly that the effects are very similar. Not calling this > "hasLayout" is mostly a question of name :-) > But then I see some small differences, even if I haven't tested too > much. One of the effects of hasLayout was to stop a background from > extending below a border. "Direction" does not seem to cause this.
Bruno, I think this is because the bugs related to elements without hasLayout (with respect to IE7 and hasLayout) do not applies to IE8. The peekaboo bug and the escaping float bug happens with elements without hasLayout. This is outlined in the MS documentation [1] about hasLayout. "In general, elements in Internet Explorer's Dynamic HTML engine are not responsible for arranging themselves. A div or a p element may have a position within the source-order and flow of the document, but their contents are arranged by their nearest ancestor with a layout (frequently body). These elements rely on the ancestor layout to do all the heavy lifting of determining size and measurement information for them." This does not apply to IE8 so I can expect that no test cases will show any jumping margins or real bugged out behaviors. > Also with margins collapsing the effects are slightly different. I > would say the effects of "dir" are more consistent with "new block > formatting context", while hasLayout had other mixed effects. I agree that this is related to a "new block formatting context" and follows what is seen in the MS documentation [1]. "Elements that do have layout may establish a new block formatting context (9.4.1 in the CSS 2.1 spec)". A note for other subscribers. Elements that establish a "new block formatting context" can not cross hasLayout boundaries. > Another reason I prefer not to "overcharge" the "hasLayout" name is > that it is just a dom property, still present in IE8 (Microsoft never > said the property has gone, only its effects), and it is still "false" > and "true", more or less in the same cases as before. What is > interesting is that if you query the property for a box with "rtl" > you get "true" in IE8, "false" in IE7-. To my understanding, if a query of the property for a box with "rtl" for IE8 is hasLayout = true, then we are seeing and element that has layout. I not to up to speed with the DOM so forgive any ignorance. > I've added the rtl case in this old page [1] of mine, look at the (javascript > generated) table, > case 24. > > Regards, > Bruno > > [1] http://brunildo.org/test/hh-rtl.html I have now done more on the test case. <http://css-class.com/test/bugs/ie/ie8-haslayout-bidi.htm> As can be seen in some test cases (1c and 2b), setting text direction to "ltr" in the CSS turns off the bug. I presume that any test where a "new block formating context" is established will show this bug. 1. <http://msdn.microsoft.com/en-us/library/bb250481%28VS.85%29.aspx> 2. <http://www.w3.org/TR/CSS21/box.html#collapsing-margins> 3. <http://www.w3.org/TR/CSS21/visuren.html#floats> -- Alan http://css-class.com/ Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo ______________________________________________________________________ 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/
