Re: [CSS21] Clearance error - hypothetical border edge should be actual border edge (Was: Re: [css2.1] Issue 158 and Issue 178 Resolution)

My analysis in this thread until now has assumed that the hypothetical
non-zero top border is still present when performing calculation 2 (and
was pondered, and preferred for symmetry, in calculation 1).

However, could it be the case that this hypothetical top border is no
longer physically present (and its position no longer relevant) when we
perform the clearance calculations?

Working through the Calculation 2 text again, under this assumption:

> height of collapsed margin lump resulting from the top margin of the
> clearing element and previous adjacent margins
> 
>     =     height of margin lump above the clearance
>        +  clearance
>        +  the clearing element's top margin (if element is self-
>           collapsing) or the height of the margin lump resulting from
>           collapsing below the clearance (otherwise)
> 
>     =     height of margin lump of previous adjacent margins
>        +  clearance
>        +  distance from the clearance to the clearing element's
>           hypothetical top border edge

The last summand is now "distance from the clearance to the pre-2007
actual top border edge".

> Which is to say (rephrasing the left-hand side):
> 
> distance above the clearing element's hypothetical top border edge to
> the top of the collapsed margin lump (prior to introducing clearance)
> 
>     =      height of margin lump of previous adjacent margins (after
>            introducing clearance, which separates these margins from
>            subsequent margins)
>        +  clearance
>        +  distance from the clearance to the clearing element's
>           hypothetical top border edge
> 

Ditto.

> The three terms on the right describe the spacings we end up with after
> introducing clearance, namely the margin lump above the clearance, the
> clearance itself, and the distance from the clearance to the (new
> position of the) hypothetical top border edge.

Ditto.

> The term on the left is
> the distance from the top of the original margin lump (before clearance
> was determined as being necessary) to the hypothetical position.

This still holds.

> In other words, clearance-2 is precisely the amount needed to return the
> hypothetical border edge, after margin collapsing has been interrupted,
> to the position it originally occupied.

Not under the new assumption.  Clearance2 is now the amount needed
to move the pre-2007 actual top border edge to the position originally
occupied by the hypothetical top border edge.  As before, by symmetry we
may prefer to interpret Calculation 1 as talking about the same edge as
calculation 2, ie the pre-2007 actual top border edge.

This would be a very curious setup.  The result of introducing clearance
would be to move the pre-2007 actual top border edge position to either
flush below the float or to the pre-clearance hypothetical top border
edge position in the case that the float moves upwards... but the
criteria for determining whether clearance is even necessary is *not*
the pre-2007 actual top border edge position.  In other words, the aim
of clearance prior to 2007 would be to typically ensure that the border
position is past the float, but it was not the pre-clearance border
position which would decide if clearance was necessary.

The same example from before highlights the strangeness of this approach:

On 16/08/2010 21:14, Anton Prowse wrote:
> <div style="border-bottom:1px solid black; margin-bottom:5px">
>     <div style="float:left; width:100px; height:50px; background:green"></div>
> </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>
> </div>

As before, the pre-clearance actual top border edge is already below the
float, so one might assume that no clearance is necessary.  However, the
hypothetical top border edge position is 20px below the top of the whole
margin lump, meaning that under the current interpretation, clearance is
introduced as zero-height margin collapsing inhibitor.  Then,
Calculation 2 considers the real box models involved without a
hypothetical non-zero top border present (meaning that the actual top
border edge is currently 105px below the top of the float), and the
clearance quantity is calculated to be either max(50-25,20-105)=25px or
max(50-105,20-105)=-55px depending on whether, respectively,
hypothetical border or actual border is meant in Calculation 1.  In the
latter case we end up with the "text" flush with the bottom of the green
float (with "text"'s margin-top having the appearance of being
impotent).  In the former case, the clearing element ends up 130px below
the top of the float, ie 30px further down than necessary.

So if actual border is meant in Calculation 1 (by symmetry with
Calculation 2), the need for clearance is decided by effectively
ignoring the top margin of the clearing element's child, and then the
clearing element is moved to below the float /also/ as if the child's
margin were non-existent.  Hence the clearance concept would be rather
peculiar – and very aggressive towards child top margin – under the
interpretation discussed in this post.


We've seen how there are two interpretations of how to perform
Calculation 1 (move hypothetical border position or pre-2007 actual
border to below the float) and two interpretations of how to perform
Calculation 2 (assume hypothetical border is still present or not, and
then respectively move either the hypothetical border or pre-2007 actual
border to the pre-clearance position of the hypothetical border).

Whatever the permutation, the initial hypothetical border position is
often, but not always, the initial pre-2007 actual border position.

None of these four permutations seem to be particularly logical or
desirable.  I continue to conclude that we want to be doing everything
surrounding clearance using the current spec's definition of real top
border position.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Tuesday, 17 August 2010 18:37:07 UTC