- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 1 Jul 2010 14:56:35 -0700
- 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 UTC