Re: [CSS2.1] 'clear' and the static position of an absolutely positioned element

Bert Bos wrote:
> On Monday 09 June 2008 16:24, fantasai wrote:
>> Mats Palmgren wrote:
>>> CSS 2.1, 10.6.4 says:
>>> [...] the static position for 'top' is the distance from the top
>>> edge of the containing block to the top margin edge of a
>>> hypothetical box that would have been the first box of the element
>>> if its 'position' property had been 'static' and 'float' had been
>>> 'none'.
>>>
>>> I suggest we add /and 'clear' had been 'none'/ to that.

>>> https://bugzilla.mozilla.org/show_bug.cgi?id=390516
>> Recorded as CSS2.1 Issue 42
>>    http://csswg.inkedblade.net/spec/css2.1#issue-42
> 
> Not sure that's a good change, but not sure I mind either.
> 
> The reason you use the static position ('position: absolute; top: auto') 
> is to overlap with with whatever comes next, e.g.:
> 
>     ... Assume some floating box here...
>     <p style="position: absolute; top: auto">
>       Some text to be shown behind the next text...
>     <p>
>       Some text that is supposed to be shown in front of the previous
>       text
> 
> If I add 'clear: left' to the second P, the first P will not be behind 
> the second P anymore. I might try adding 'clear: left' to the first P, 
> too...

I'm not sure I'm motivated by Bert's use case (I've never needed 
overlapping text) but I provided a different Real World(TM) use case in 
the bugzilla report listed above showing that I had to introduce a div 
wrapper into the markup to get around the issue of clear being ignored.

The following is obvious but perhaps worth writing down: if clear is 
ignored, markup hacks have to be used to recover it, whereas if it is 
not ignored, the author can always simply not use the clear property if 
they don't want it.

Of course, with most browsers ignoring it, it's probably too late to 
change this behaviour anyway.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Thursday, 31 July 2008 19:10:58 UTC