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

On 24/08/2010 02:46, fantasai wrote:
> On 08/23/2010 03:40 PM, fantasai wrote:
>> On 08/17/2010 11:35 AM, Anton Prowse wrote:
>>> 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?
>>
>> So, if I'm understanding this all correctly (which I very well might
>> not), the spec changes to fix this section would be:
>>
>> # 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. <del>This position is
>> # determined after the top margin of the element has been collapsed
>> # with previous adjacent margins (including the top margin of the
>> # parent block).</del> <ins>This position is the same as the where
>> # the actual top border edge would have been if the element had a
>> # non-zero top border and its 'clear' property had been 'none'.</ins>
>> #
>> # If this hypothetical position of the element's top border edge is
>> # not past the relevant floats, then clearance <del>must be</del>
>> # <ins>is introduced, and margins collapse according to the rules
>> # in 8.3.1.
>> #
>> # Then the amount of clearance is</ins> set to the greater of:
>> #
>> # 1. 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.
>> # 2. <del>The amount necessary to make the sum of the following...</del>
>> # <ins>The amount necessary to place the top border edge of the block
>> # at its hypothetical position.</ins>
> 
> The above is editorial clarifications to how clearance works.

I believe that these edits do succeed in clarifying how clearance works
according to the current spec.

Firstly, it's now clear how the hypothetical top border position is
defined in order to determine whether clearance is necessarily.

Secondly, it's now clear that once clearance has been deemed to be
necessary, the result of introducing it inhibits certain margin
collapsing as per 8.3.1 even without yet knowing what the clearance
amount actually is.

Thirdly, the equation for Calculation 2 has been replaced by a clear
description of what the resulting quantity is designed to achieve.

The only unresolved point is that in Calculation 1, it's not clear which
"border edge" (top/bottom) is being talked about; common sense dictates
that it's the top border edge.  Clarification of this would allow us to
confidently state that it's the real top border edge that is moved into
position in Calculations 1 and 2.

Hence for me, these edits are close to being a suitable resolution to
Issue 158, in that they make this section comprehensible and internally
consistent.


However, I believe that more work is necessary to make this section
*sensible*, which is the subject of this new thread:

> The error that Anton's pointing out in
>   http://lists.w3.org/Archives/Public/www-style/2010Aug/0309.html
> would be fixed, I believe, by sync'ing 8.3.1 and 9.5.2 by changing
> "non-zero top border" to "non-zero bottom border" to be consistent
> with the change introduced by CSS2.1 Issue 6
>   http://wiki.csswg.org/spec/css2.1#issue-6

The error, taking the above edits as given, does indeed partly result
from that change in how top border position was calculated in general.
There is a natural top border edge position for all block-level boxes
except when the element is self-collapsing.  In that case, we must defer
to 8.3.1.6 which defines the position.  The change in 2007 was to
calculate this position under the temporary assumption of a bottom
border rather than the temporary assumption of a top border.

However, I don't believe the suggested edit to be an appropriate
solution to the error, since

(a) it seems like a fairly mystifying thing to find in 9.5.2 if one
doesn't already have intimate knowledge of 8.3.1 (because it's entirely
non-obvious why that constraint would be necessary or relevant);

(b) It doesn't result in the hypothetical top border position being
incident with the actual top border position in some cases where
8.3.1.6.1 applies:

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

Under the suggested edit, when assuming clear:none in order to determine
whether clearance is introduced, the hypothetical top border position of
the clearing element is obtained by introducing a temporary bottom
border; this results in a position 20px below the top of the float.
However, under the rules of 8.3.1.6.1, the real top border position of
the clearing element is the same as that of the parent element, which is
100px below the top of the float.

[The suggested edit would cause clearance to be introduced whereas using
the real top border position would not.  Specifically, using the real
top border position would result in text 100px below the top of the
float, whereas using the suggested edit would cause the clearing element
to no longer collapse with its parent's top margin, which would invoke
8.3.1.6.2 for finding the clearing element's current real top border
position, which is determined by assuming a temporary bottom border and
hence is 20px below the top of the float.  Calculation 1 then gives us
clearance1 = 50px-20px = 30px, whilst Calculation 2 gives us clearance2
= 20px-20px = 0; hence clearance = 30px and the clearing element is
moved so that its real top border position is flush with the bottom of
the float.  Its bottom margin gives a further 100px offset below the
float, and the text ends up 150px below the top of the float – 50px
lower than necessary.]

We see how the suggested edit merely changes the problem from a mismatch
with 8.3.1.6.2 to a mismatch with 8.3.1.6.1.


To resolve the issue raised in this thread, we need to avoid describing
/how/ to determine the hypothetical top border edge altogether.  It's
none of 9.5.2's concern how the border edge is defined.  9.5.2 should
merely confine itself to its responsibility of ensuring that the border
edge is moved appropriately in the presence of floats.  I suggest the
following change to resolve both this issue and Issue 158:

   # 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<del>. This position is
   # determined after the top margin of the element has been collapsed
   # with previous adjacent margins (including the top margin of the
   # parent block).</del> <ins>as if the value of its 'clear' property
   # had been 'none', as per the rules in 8.3.1.</ins>
   #
   # If this hypothetical position of the element's top border edge is
   # not past the relevant floats, then clearance <del>must be</del>
   # <ins>is introduced and margins collapsed anew according to the rules
   # in 8.3.1.
   #
   # Then the amount of clearance is</ins> set to the greater of:
   #
   # 1. The amount necessary to place the <ins>top</ins> border edge of
   #    the block even with the bottom outer edge of the lowest float
   #    that is to be cleared.
   # 2. <del>The amount necessary to make the sum of the
   #    following...</del>
   #    <ins>The amount necessary to place the top border edge of the
   #    block at the previously-computed hypothetical position.</ins>

A note about why Calculation 2 might be necessary would also be very
valuable here, I think.

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

Received on Tuesday, 24 August 2010 17:25:40 UTC