Re: Issue 158 proposed text

Tab Atkins Jr. wrote:
> So, then, current proposal for fixing issue 158.  As a reminder, it's
> meant to address the issue found at
> http://wiki.csswg.org/spec/css2.1#issue-158 and replace the text found
> at http://www.w3.org/TR/CSS2/visuren.html#flow-control .
> 
> | 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]?


> | 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] http://lists.w3.org/Archives/Public/www-style/2010Jun/0639.html
[2] http://lists.w3.org/Archives/Public/www-style/2010Apr/0484.html
[3] http://lists.w3.org/Archives/Public/www-style/2010Jan/0514.html

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

Received on Thursday, 1 July 2010 21:50:40 UTC