W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: [CSS21] margin-collapse-164 is currently invalid per section 9.5.2

From: Anton Prowse <prowse@moonhenge.net>
Date: Sat, 05 Feb 2011 13:01:16 +0100
Message-ID: <4D4D3C0C.9070108@moonhenge.net>
To: Arron Eicholz <Arron.Eicholz@microsoft.com>
CC: "L. David Baron (dbaron@dbaron.org)" <dbaron@dbaron.org>, "hyatt@apple.com" <hyatt@apple.com>, "Ian Hickson (ian@hixie.ch)" <ian@hixie.ch>, "fantasai (fantasai@inkedblade.net)" <fantasai@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>, "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
On 28/12/2010 18:06, Arron Eicholz wrote:
> http://test.csswg.org/suites/css2.1/20101210/html4/margin-collapse-164.htm
> http://test.csswg.org/suites/css2.1/20101210/html4/margin-collapse-clear-005.htm
> http://test.csswg.org/suites/css2.1/20101210/html4/margin-collapse-clear-011.htm
> These test cases exhibit a margin collapse behavior that we have discussed many times, however after some extensive review it seems as if the cases themselves are incorrect per the current spec. These cases should be updated to match the latest spec.

I believe these tests *are* correct according to the current spec 
(although I'm petitioning strongly for the spec to be changed to address 
unrelated issues: [1]).

> Section 9.5.2 states:
> Computing the clearance of an element on which 'clear' is set is done by first determining the hypothetical position of the element's top border edge within its parent block. This position is where the actual top border edge would have been if the element had a non-zero bottom border and its 'clear' property had been 'none'.

> Using margin-collapse-164 as our example case...

> Based on section 9.5.2 we first calculate the hypothetical position, within its parent block, of div "clear". We collapse the top margin of "clear" with "box" which puts the "clear" element's top position at 0. We then place the div "float" into the mix. Div "float" element's top position is also at 0

Right, so assuming clear:none, the top margin of "clear" collapses with 
its parent, meaning that the top border positions of the parent, the 
float, and "clear" are incident at 3em below the top border of "outer".

> which will trigger the "clear" element to clear since the two intersect.

Indeed. We now have to assume the "clear" element no longer collapses 
its top margin with the parent, and we perform the two calculations and 
take the max.

> Since we now clear it will look as if the "clear" element's margin was completely ignored (in reality you end up with negative clearance). Thus the "clear" element will be touching the bottom of the "float" element.

No.  That's the result of the first calculation: "The amount necessary 
to place the border edge of the block even with the bottom outer edge of 
the lowest float that is to be cleared."

The second calculation is "The amount necessary to place the top border 
edge of the block at its hypothetical position", which is a greater amount.

The test is correct.

> Currently all browsers I have tested in Windows, IE8, IE9, Firefox3.6.13, Firefox 4b8, Opera 11, Safari 5.0.3, Chrome 8.0.552.224, Konquerer 4.4.0 all exhibit the same visual result.

Indeed.  The browsers never seemed to implement the second calculation.

> This means that we all are in compliance to what the spec statestoday. However the tests assume a different behavior.


(I claim the spec should be changed to use real top border position of 
the "clear" when calculating the hypothetical position under the 
assumption of clear:none., not the bottom border position.  However, 
that has no bearing on the use or otherwise of the second calculation; 
it's a separate issue.[1])

Bear in mind that the second calculation was introduced precisely to 
ensure that there is no mysterious disappearance of white space (in this 
case, the "clear"'s top margin).[2]  The WG may wish to abandon the 
second calculation to match implementations, but then they are diverging 
from the stated goal.[3]

[1] http://lists.w3.org/Archives/Public/www-style/2010Sep/0665.html
[2] http://dbaron.org/log/2007-03#e20070329a
[3] pers. comm. from fantasai based on a thread in the private archives

Anton Prowse
Received on Saturday, 5 February 2011 12:05:14 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:55 UTC