Re: Issue 158 proposed text

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.



> 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).


> <div style="border: 1px solid">
>        <div style="float:left; width:15px; height:15px"></div>
>        <div style="margin: 10px 0">
>                <div style="clear:both; margin: 10px 0 20px">
>                        <div style="margin: 15px 0"></div>
>                </div>
>        </div>
> </div>
>
> Does the 15px combined margin of the clearing element's child combine
> with the clearing element's 10px top margin or its 20px bottom margin?
>
> If it combines with the 20px bottom margin, then the clearing element's
> 10px top margin combines with its parent's 10px top margin, and the top
> borders of these latter two elements are incident at 10px below the top
> of the float, as per 8.3.1.6.1.
>
> However, if it combines with the 10px top margin then the combined
> margin is 15px, which combines with the clearing element's parent's 10px
> margin giving a resulting 15px margin, which means that the border top
> of the latter parent -- and hence of the clearing element itself -- is
> 15px below the top of the float, again as per 8.3.1.6.1.
>
> In the latter scenario, the position of the top border of the clearing
> element is flush with the bottom of the float, whereas in the former
> scenario it's above the bottom of the float.  Hence the determination of
> whether clearance is introduced is affected.
>
>
> Note that the ambiguity is benign if the clearing element's margins
> don't collapse with its parent's top margin (for instance, because the
> parent has a non-zero top border width); in that case 8.3.1.6.2 applies
> and so the clearing element's top border edge is the same as it would
> have been if that element had a non-zero bottom border, which more or
> less dictates that its child's combined 15px margin combines with its
> top margin rather than its bottom margin for the purposes of calculating
> the position of its top border.


Yes, and so saying that the hypothetical position is (always) computed
assuming the element has a non-zero bottom border fully eliminates
this ambiguity. And seems to give the expected/intended results.


>
>>> [1] http://lists.w3.org/Archives/Public/www-style/2010Jun/0639.html
>
> Cheers,
> Anton Prowse
> http://dev.moonhenge.net


Best,
Bruno

-- 
Bruno Fassino http://www.brunildo.org/test

Received on Sunday, 4 July 2010 14:14:15 UTC