- From: Anton Prowse <prowse@moonhenge.net>
- Date: Sat, 05 Feb 2011 13:01:16 +0100
- 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. No. (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 Cheers, Anton Prowse http://dev.moonhenge.net
Received on Saturday, 5 February 2011 12:02:37 UTC