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

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.

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Anton Prowse
Sent: Friday, June 06, 2008 1:36 PM
To: www-style@w3.org
Subject: Re: [CSS 2.1] static position of an absolutely positioned element with auto-offsets


fantasai wrote:
>
> Ingo Chao wrote:
>> The static position is the position an element would have had in the
>> normal flow --  separated in vertical and horizontal direction.
>>
>> But this sentence seems to encourage diversity:
>> "...user agents are free to make a guess at its probable position"
>> (CSS 2.1: 10.3.7 and 10.6.4).
>>
>> IE places an absolutely positioned box with auto-offsets /alongside/ a
>> float. Does this behavior violate the spec or not? I think it should.
>
> Would s/probable position/probable vertical position/ solve this problem?

The issue is that it is not clear why freedom was granted in the first
place.  Maybe it was a nod to pre-existing UA diversity, but quite
possibly it is because it is computationally expensive to first flow an
AP element (and possibly surrounding elements) in order to calculate its
static position and then to flow it (and them) again to render it as an
AP for which different layout rules apply.  The underlying reason needs
to be clarified before the value of any given resolution can be assessed.

Anton Prowse
http://dev.moonhenge.net

Received on Friday, 6 June 2008 21:11:11 UTC