Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 390516 - clear property ignored when calculating static position of absolutely positioned element
: clear property ignored when calculating static position of absolutely positio...
Product: Core
Classification: Components
Component: Layout: R & A Pos (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
Depends on:
  Show dependency treegraph
Reported: 2007-08-01 12:58 PDT by Anton P.
Modified: 2009-04-18 06:05 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Minimal test case illustrating the issue (1.36 KB, text/html)
2008-03-11 13:31 PDT, Anton P.
no flags Details

Description Anton P. 2007-08-01 12:58:16 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv: Gecko/20070508 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv: Gecko/20070508 Firefox/

CSS 2.1 CR [] states the following (which, for the purposes of this bug, is that same as what is stated by CSS 2 []):

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.

Reproducible: Always

Steps to Reproduce:
Alternate the positioning scheme of the second div between static and absolute.
Actual Results:  
The second div changes position depending on its positioning scheme.

Expected Results:  
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.
Comment 1 Mats Palmgren (:mats) 2007-08-01 15:15:44 PDT
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?
Comment 2 Anton P. 2008-03-11 13:31:52 PDT
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: .

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.
Comment 3 Mats Palmgren (:mats) 2008-03-11 20:03:15 PDT
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'"
in 10.3.7?
Comment 4 fantasai 2008-03-12 00:40:17 PDT
If David Baron agrees that the change should be made, then I will add it to the CSS2.1 issues list for discussion.
Comment 5 Daniel.S 2009-04-18 06:05:20 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.