


From: Anton Prowse <prowse@moonhenge.net>
Date: Mon, 16 Aug 2010 21:14:51 +0200
Message-ID: <4C698E2B.2080207@moonhenge.net>
I believe my analysis of what the spec is trying to say ("apply the
expected clearance mechanism but use the position of a hypothetical top
border edge") is correct, and also my conclusion ("do the same thing
but use the actual top border edge position instead").

However, a correction is required to my side-note in which I tried to
establish how we even arrived at a situation in which a mistaken notion
of border edge position is being used:

On 15/08/2010 10:16, Anton Prowse wrote:
> But what /is/ this hypothetical top border edge?  We're not interested
> in some hypothetical edge! We're interested in the *actual* edge, right?
>  Well, the hypothetical edge /is/ the actual edge, in the case that an
> actual non-zero edge exists (either its own edge,

> or if not, that of its
> first in-flow child that has an edge, etc, according to 8.3.1).
false in general

> But in
> the case that there's no "natural" edge – which is to say, in the case
> that the clearing element is self-collapsing – the actual edge position
> is that determined in _which used to be the position of a
> hypothetical non-zero top border edge, in other words the hypothetical
> top border edge_.

It was incorrect to say that the hypothetical edge is the actual edge in
the case where a non-self-collapsing clearing element has no non-zero
top border and collapses its top margin with a larger margin lump
arising from its first in-flow descendants.  For example:

<div style="border-bottom:1px solid black; margin-bottom:5px">
	<div style="float:left; width:100px; height:50px; background:green"></div>
<div style="clear:left; margin-top:20px">
	<div style="float:left; width:10px; height:10px; background:red"></div>
     <div style="margin-top:100px">text</div>

In this case, the hypothetical top border edge position (20px below the
top of the whole margin lump) isn't the actual top border position
(100px below the top of the whole margin lump).  This means that the
9.5.2 text didn't even match the pre-2007 border box convention.  I can
only imagine that this was a bug in 9.5.2 in the old spec.  That is, I
imagine that the 9.5.2 text /wanted/ to use the old notion of border
position but made a mistake in the particular case just illustrated.
(We really don't expect clearance to be introduced in the example given,
do we?)  Hence the 9.5.2 text is even less sensible than feared.

In the example given, when using actual border (which is already below
the float), no clearance is deemed necessary.  However, when using the
current text, clearance is necessary and when it is initially introduced
as zero-height margin collapsing inhibitor the hypothetical position
becomes 25px below the top of the float, and so the clearance quantity
is calculated to be either max(50-25,-5)=25 or max(50-105,-5)=-5
depending on whether, respectively, hypothetical border or actual border
is meant in Calculation 1.  In the latter case we end up with the same
rendering as we do when we use actual border (so no harm done by the
spec bug).  In the former case, the clearing element ends up 130px below
the top of the float, ie 30px further down than necessary.

I noted previously that by using the pre-2007 notion of border position
instead of the new notion, the case of self-collapsing clearing elements
resulted in the clearing element sometimes being moved down too far.
Now we see that with the spec bug, this can happen even for
non-self-collapsing elements.

As I said to begin, my conclusion as to what the spec does say and
should say still stands.  But in this post we see that what it does say
is less explicable than I first thought.

[Just for interest: in my browser testing with the example given and
other related examples,  I observed that Op10.6 follows the spec, moving
the clearing element 30px further down than its clear:none position.
Happily, Fx3.6, Sf5 and IE8 appear to do the computations using the
actual border edge position and decide that clearance isn't necessary.
I know that IE8 isn't so well-behaved in closely related test cases though!]

Anton Prowse
Received on Monday, 16 August 2010 19:16:54 GMT
