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

Re: Issue 158 proposed text

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 5 Jul 2010 01:41:54 -0700
Message-ID: <AANLkTikzhnvFKDOye50zm97XPzv6o-DMmHmScCQIOeOD@mail.gmail.com>
To: Anton Prowse <prowse@moonhenge.net>
Cc: www-style list <www-style@w3.org>
On Sun, Jul 4, 2010 at 3:40 AM, 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.

Oh, I see, I was still thinking about the earlier use of the term,
which I'd replaced with "adjoining".

"Preceding" there means precisely what it sounds like - the margins
that precede that element's top margin.  That is, the element's
preceding siblings, the element's parent, and so on.  The element's
children's margins are certainly not preceding - they don't come
before the element's top margin in any conceivable way.

(The use of "preceding" was previously bad because it was wrong - we
wanted to include the element's children's margins as well when
calculating the hypothetical position.)

I don't think it's particularly necessary to clarify the term, but I
can add a bit of language specifying what I said above.


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

Ah, I see the ambiguity.  When a child's margin would normally
collapse with both margins of the clearing element, it instead
collapses with only the top margin.

~TJ
Received on Monday, 5 July 2010 08:42:47 GMT

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