User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:220.127.116.11) Gecko/20070508 Firefox/18.104.22.168
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:22.214.171.124) Gecko/20070508 Firefox/126.96.36.199
CSS 2.1 CR [http://www.w3.org/TR/2007/CR-CSS21-20070719/visudet.html] states the following (which, for the purposes of this bug, is that same as what is stated by CSS 2 [http://www.w3.org/TR/CSS21/visudet.html]):
10.6.4 Absolutely positioned, non-replaced elements
[...] the term "static position" (of an element) refers, roughly, to the position an element would have had in the normal flow. More precisely, 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'.
But rather than actually calculating the dimensions of that hypothetical box, user agents are free to make a guess at its probable position.
However, the minimal test case given in the URL for this bug shows that the property "clear: both" is ignored when calculating the static position for 'top' of an absolutely positioned element, and hence this AP element's static position is very different from its actual position when it is non-AP, since it follows a float.
Steps to Reproduce:
Alternate the positioning scheme of the second div between static and absolute.
The second div changes position depending on its positioning scheme.
The second div should be rendered in the same position (beneath the floated first div), regardless of whether its positioning scheme is static or absolute.
Since most UAs(*) have the same layout for the URL it seems more appropriate
to update CSS 2.1 to say that 'clear' should be considered to be 'none'
when calculating the static position.
(*) All Gecko-based UAs, Opera9.22, Webkit/Safari/Konqueror.
IE7 being the exception, however IE7's implementation of abs.pos. has so
many errors I'm not sure it's really worth considering in this context.
It reminds me of bug 168971, David was 'clear' discussed at that time?
Created attachment 308701 [details]
Minimal test case illustrating the issue
Replaced URL with an attachment. IE8 beta 1 also ignores the 'clear' property when 'position' is set to absolute, so with all major graphical desktop UAs showing this behaviour I guess the CSS 2.1 spec should be updated.
IMO this behavior is a shame, however, because I cannot think of a real-world situation in which it would be useful to AP something over the top of a float, whereas the following URL shows an example where it would have been useful to honor the 'clear' propery: http://www.thelodgehotellondon.com/meetings-en.html .
In that example, AP'ing the final div#small-print without specifying 'top' or 'bottom' allows that div to "drop out" of its parent container div#holder, thereby permitting it to have a different background from this parent while still being contained by the parent in the source code (as semantically required). However, because the 'clear' property is ignored, and because the elements above it in the layout are floats, the div#small-print is positioned uselessly on top of these floats unless I wrap them in a non-floated container div#fact-content, thus creating an artificial semantic relationship between them in the markup.
fantasai, assuming the change in IE8 beta1 isn't a bug, this would make
all popular UAs compatible (see comment 1). I think it would be a good
idea to make this an explicit requirement in the spec.
How about adding "'clear' had been 'none'" nearby "'float' had been 'none'"
If David Baron agrees that the change should be made, then I will add it to the CSS2.1 issues list for discussion.
Erratum 49 of the 17 July 2007 CR defines, that when calculation the static position of an abs. pos. element, neither float nor clear are taken into account.
This also resembles IE8's implementation.