Re: Issue 158 proposed text

Bruno Fassino wrote:
> On Sun, Jul 4, 2010 at 12:40 PM, Anton Prowse <prowse@moonhenge.net> wrote:
>> Tab Atkins Jr. wrote:
>>> 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.
>>>
>> I can't tell if we're talking about the same thing!  What I meant was is
>> that you've reintroduced the term "preceding margins" in the prose
>> without defining what it means for a margin to be preceding.  (Eg, it's
>> still not clear to me from the 9.5.2 prose whether the first in-flow
>> child's top margin collapses with the clearing element's top margin once
>> clearance has been deemed necessary via the hypothetical position
>> calculation, although 8.3.1 very much indicates that it is: "When an
>> element's own margins collapse, and that element has had clearance
>> applied to it, [...]".)  If this term relates to your description of
>> which margins collapse when calculating the hypothetical position, then
>> it should be made explicit.
> 
> 
> I don't think the term "preceding" here refers to the margins used for
> the hypothetical position calculation.
> Here it just refers to the fact that:
> - there is something new above the element's top margin (the
> clearance, even if possibly 0) separating it from (= making it not
> adjacent to) margins "above" (parent top margin, preceding
> siblings...)
> How to express this more precisely, I don't know.

Do we have to mention it at all?  I'm concerned that we're setting
ourselves up for a fall by doing so.  The rules for margin collapsing --
including where clearance is involved -- are clearly specified in 8.3.1
and I don't see any benefit of trying to restate them in 9.5.2.  Let's
just defer to 8.3.1 in the case that we've determined that clearance be
necessary.  (The spec has something of a history of getting itself into
trouble through unnecessarily restating complicated things in different
places and not getting the details quite right.)

In particular, although the primary effect of clearance on an element is
to prevent its top margin from collapsing with proceeding margins (in
the sense that you describe), there's also that curious rule about
preventing the bottom margin of a block from collapsing with a previous
combined margin if such margin arose in part from an self-collapsing
clearing element.  That doesn't get mentioned in the proposal for 9.5.2,
a fact which is anomalous and potentially confusing.


>> The current proposal also contains an ambiguity:
>>
>> | 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.
>>
>> You're deferring to the normal margin-collapsing rules, and yet you're
>> constraining how they're supposed to be applied; you can only do this is
>> you then redefine how the normal margin-collapsing rules work under this
>> constraint.
>>
>> In particular, when you say that the clearing element's top margin is
>> not allowed to collapse with its bottom margin, I assume you mean that
>> the two margins must be regarded as non-adjacent (to use the terminology
>> of 8.3.1, which I recommend doing).  But what if the clearing element
>> contains an only child whose top and bottom margins collapse?  This
>> combined child margin would ordinarily be adjacent to the clearing
>> element's top and bottom margins and hence would combine with both.
>> However, since you're preventing the clearing element's top and bottom
>> margins from collapsing in your hypothetical position calculation, you
>> need to state how the combined child margin interacts with the parent
>> margins.
> 
> 
> Re-reading again this part of the proposed definition of hypothetical position:
> 
> | except that the clearing element's top margin is not allowed
> | to collapse with the clearing element's bottom margin
> 
> I agree that probably it is still ambiguous. I mentioned in a previous
> message using instead of that exception something like:
> 
> | but assuming the clearing element has a non-zero bottom border
> 
> (this locution is already used at 8.3.1 to identify the position if a
> collapsed through element top border).
> This formulation leaves no ambiguity: in particular margins of first
> inflow children will be considered  (allowed to collapse with the
> element top).
> 

Until now I had only been skimming your discussion with Tab.  Now that
I've looked back at it more carefully, I see that you did indeed already
express doubts about such an ambiguity, and I agree that a proposal like
the one you're making -- using normal margin collapsing rules on a
tweaked style foundation (temporary introduction of non-zero bottom
border), rather than trying to tweak the margin collapsing rules
themselves -- is a suitable way of avoiding the problem.  Indeed, my
mail should ideally have been a response to Tab's comment in [1]:

'Saying "assume the element has a non-zero bottom border", though, is
just an indirect way of saying "don't let the element's top and bottom
margins collapse together"'

which is in fact not the case, as the ambiguity shows.


This clearance + margin collapsing business is a real vipers nest, isn't
it!  I'm currently working through your arguments in [2] as to why it's
not good enough to just calculate the hypothetical position under normal
margin collapsing rules and without making any style tweaks, which would
superficially be the most natural thing to do and which Tab initially
proposed.


[1] http://lists.w3.org/Archives/Public/www-style/2010Jun/0672.html
[2] http://lists.w3.org/Archives/Public/www-style/2010Jun/0637.html

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

Received on Sunday, 4 July 2010 16:59:19 UTC