Re: [CSS 2.1] static position of an absolutely positioned element with auto-offsets

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