W3C home > Mailing lists > Public > www-style@w3.org > July 2010

Re: Issue 158 proposed text

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 1 Jul 2010 14:56:35 -0700
Message-ID: <AANLkTik0xP4OvcxhiqRrH_DwDTcOxiEQIzX3BH3sPshu@mail.gmail.com>
To: Anton Prowse <prowse@moonhenge.net>
Cc: www-style list <www-style@w3.org>, Bruno Fassino <fassino@gmail.com>
On Thu, Jul 1, 2010 at 2:49 PM, Anton Prowse <prowse@moonhenge.net> 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
>> 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]?

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:

Sure.


>> | * 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

Agreed!

~TJ
Received on Thursday, 1 July 2010 21:57:31 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:29 GMT