Re: Issue 158 proposed text

On Thu, Jul 1, 2010 at 2:49 PM, Anton Prowse <> wrote:
> Tab Atkins Jr. wrote:
>> So, then, current proposal for fixing issue 158.  As a reminder, it's
>> meant to address the issue found at
>> and replace the text found
>> at .
>> | 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
>> | determined after the top margin of the element has been collapsed
>> | with all appropriate adjoining margins per normal margin-collapse
>> | rules, except that the clearing element's top margin is not allowed
>> | to collapse with the clearing element's bottom margin.
>> |
>> | If this hypothetical position of the element's top border edge is
>> | flush with or past the relevant floats, then no clearance is
>> | applied. Otherwise, the top margin of the element no longer
>> | collapses with preceding margins,
> Doesn't this reintroduce the "preceding margins" ambiguity that was
> potentially resolved in [1]?

No, as I'm no longer trying to make a special distinction about it
only collapsing with certain types of margins.  It just collapses with
everything that it would normally collapse with, except for the one
exception I specify.  This exception properly excludes everything I
want to exclude - in essence, it captures the notion of "preceding"
more precisely, but without the chance of accidentally overruling
normal margin-collapse rules.

>> | and the clearance is set to the greater of:
> With respect to the resolution of the clearance paradox in [2], I think
> it would be preferable to express this along the lines of:
>  | and clearance is introduced and is set to the greater of:


>> | * The amount necessary to place the top border edge of the block
>> |   even with the bottom outer edge of the lowest float that is to be
>> |   cleared.
>> | * The amount necessary to place the top border edge of the block
>> |   even with the previously computed hypothetical position of the top
>> |   border edge of the element.  (Informative Note: This is necessary
>> |   to handle the case where the float moves due to the element's top
>> |   margin no longer collapsing with previous margins.)
>> Changes from the current spec text:
>> [...]
>> 2. The second bullet point has been rewritten to capture the intent in
>> a clearer manner, and has an informative note explaining the intent,
>> because it's really not obvious on a quick read.
> I'm a big fan of this kind of thing, and I wish it were applied more
> frequently in this and future specs.  (See [3] for my lightbulb moment
> regarding the purpose of the second clearance calculation.)  The author
> in me is more interested in knowing /what/ a rule is trying to achieve
> than /how/ it achieves it.  (Additionally, from the debugger's
> perspective, it reminds me of the age-old situation in which programming
> students resent commenting their code, stating that their code is
> self-explanatory – to which the standard response is that the code tells
> me what the code does, whereas the comments tell me what they /hope/ the
> code does – and alas these don't always coincide.)
> [1]
> [2]
> [3]



Received on Thursday, 1 July 2010 21:57:31 UTC