- From: Alan Gresley <alan@css-class.com>
- Date: Sat, 07 Jun 2008 08:03:00 +1000
- To: Alex Mogilevsky <alexmog@exchange.microsoft.com>
- CC: Anton Prowse <prowse@moonhenge.net>, "www-style@w3.org" <www-style@w3.org>
Alex Mogilevsky wrote: > This passage in the spec is actually one of my favorites. "free to make a guess" is a great way to define things! > > On IE behavior: > > * in IE up to IE7, "static" position of a positioned object is determined as if it was an inline element with zero width. When this was implemented (many years ago) we believed that since absolute elements always become blocks, it is logical to produce same result for absolutely positioned blocks and inlines. > > * However, by now there appears to be a consensus in other browser that static position for a block element on the next line, as if it was in fact a block. > > * IE8 (in standards mode) changes the guessing algorithm to also pay attention to "display" property and put static position of a block in the next line, with appropriate alignment. > > On the spec: > > It is hard to define exactly what position an element "would have had" in normal flow because if it was in flow it would affect the document. The only way to define that precisely is to actually layout with the element in flow, take its position, then relayout without the element. That would be costly, and most likely less predictable. > > The current practice is still somewhat ambiguous but reasonably predictable. We will definitely add a more precise definition in CSS3. Hi Alex, I would say this has more to deal with the static position (left:auto) of an a.p element within it's containing block, 'block formating context' CSS2.1: 9.4.1. Ingo refers to CSS 2.1: 10.3.7 and 10.6.4 which deal with calculating width, heights and margins but in particular markup and a.p. element will behave more like a float if appearing after a float. The rendering could have been associated with hasLayout but considering that IE8b now positions the a.p. element the same way as IE7 or IE6 did, then it not a hasLayout bug (for at least IE8b). I have two test cases showing unexpected behavior. I have declared them as bugs but they are more in a sense undefined behavior. The first instance is when an a.p. box follows an inline element in the source. http://css-class.com/test/bugs/ie/calculated-offset-bug1.htm The second instance is when an a.p. box follows a floated element in the source. http://css-class.com/test/bugs/ie/calculated-offset-bug2.htm IE will offset the a.p. to the left of the inline element or float where all other implementation will offset the a.p. to the left edge of it containing block (which I think is the correct behavior). In non IE implementations, with the former case the a.p. element will appear beneath an inline element and with the later case the a.p. element will appear layered above the floated element. In respect to CSS 2.1: 10.3.7 and 10.6.4 I don't know how IE behaves since a margin-left would I think only come into play once it's width exceeds the width of the float. I think the CSS2.1: 9.4.1 would have to be resolved first. Leaving this to CSS3 to resolve I think is a big mistake. Alan
Received on Friday, 6 June 2008 22:04:03 UTC