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

Thanks for test cases. I am not sure what IE8 beta 1 does there, we'll make sure it is correct in beta2. You expected behavior matches my understanding.

As far as not adding precise specification to CSS2.1 - it would be great but it is far beyond the kind of changes CSS2.1 can take at this stage... Having it written up in CSS3 would still be very helpful.

-----Original Message-----
From: Alan Gresley [mailto:alan@css-class.com]
Sent: Friday, June 06, 2008 3:03 PM
To: Alex Mogilevsky
Cc: Anton Prowse; www-style@w3.org
Subject: 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:22:01 UTC