Re: [CSS2.1] Clarifying 8.3.1 Collapsing Margins

On 09/14/2010 04:44 PM, L. David Baron wrote:
> On Thursday 2010-08-19 11:36 -0700, fantasai wrote:
>> This is for CSS2.1 Issue 159
>>    http://wiki.csswg.org/spec/css2.1#issue-159
>> triggered by this email
>>    http://lists.w3.org/Archives/Public/www-style/2010Feb/0015.html
>>
>> This is version 3.
>>
>>   | In CSS, the adjoining margins of two or more boxes (which could be
>>   | siblings or nested) can combine to form a single margin.
>
> The "(which could be siblings or nested)" seems too limiting; as the
> note below says, they could be in many other configurations, but
> this could be interpreted to restrict them to only those
> configurations.  I'd suggest dropping the parenthetical.

Changed to "might or might not be siblings" to leave in the clarification.

>>   | Margins that combine this way are said to<dfn>collapse</dfn>, and
>>   | the resulting combined margin is called a<dfn>collapsed margin</dfn>.
>>   |
>>   | Adjoining vertical margins collapse, except:
>>   |   * Margins of the root element's box do not collapse.
>>   |   * If the top and bottom margins of an element with clearance are
>>   |     adjoining, its margins collapse with the adjoining margins of
>>   |     following siblings but that resulting margin does not collapse
>>   |     with the bottom margin of the parent block.
>>   | Horizontal margins never collapse.
>>   |
>>   | Two margins are adjoining if and only if:
>>   |   * both belong to normal-flow block-level boxes that participate
>>   |     in the same block formatting context
>
> Since we don't actually define "participate in" a block formatting
> context, I think it's important to also say here that neither of the
> boxes is the box that establishes the block formatting context.

I would prefer to define participation in a block formatting context,
since the margins of boxes that establish block formatting contexts
can and do collapse e.g. with siblings or parents, and that makes
this requirement hard to word...

We already say that block-level boxes "participate in a block formatting
context". Would it be sufficient to add in 9.4.1 that certain elements
"establish a new block formatting context >for their contents<"?
Or is something more necessary here?

>>   |   * no line boxes, no clearance, and no non-empty padding or border
>>   |     areas separate them
>>   |   * both belong to vertically-adjacent box edges, i.e. form one of
>>   |     the following pairs:
>>   |       - top margin of a box and top margin of its first in-flow child
>>   |       - bottom margin of box and top margin of its immediately
>>   |         following in-flow sibling
>
> I'd suggest dropping "immediately".  I think the immediacy that's
> required is covered by the point before (no line boxes, no
> clearance, etc.), and this could be interpreted to break margin
> collapsing in cases where it should not be broken (floats, collapsed
> whitespace).
>
> In fact, it might need clarification to say that a "following
> in-flow sibling" could be a later sibling if intervening siblings
> are out-of-flow.

Wrote "next in-flow following sibling". I hope that's sufficiently
clear.

>>   |       - bottom margin of a last in-flow child and bottom margin
>>   |         of its parent if the parent has 'auto' height
>
> I think this should specifically refer to "computed height" rather
> than just "height".

Ok.

> I think this also needs to say that 'min-height' is nonzero, but
> that's a fix to a transitivity bug existing in the current spec.

I'd like to address that as a separate issue. I'd like to keep this
one purely editorial.

>>   |       - top and bottom margins of a box with zero used height and
>>   |         no in-flow children
>
> As I mentioned in the telecon, changing this to refer to "used
> height" is a substantive change that, as we discussed, appears to
> disagree with implementations.  This should be changed back to
> saying that the computed 'min-height' is '0' and computed 'height'
> is '0' or 'auto'.

Fixed.

>>   |   * The top margin of an in-flow block element collapses with
>>   |     its first in-flow block-level child's top margin if the
>>   |     element has no top border, no top padding, and the child has
>>   |     no clearance.
>>   |   * The bottom margin of an in-flow block element with a
>>   |     'height' of 'auto' collapses with its last in-flow block-level
>>   |     child's bottom margin if the element has no bottom padding and
>>   |     no bottom border and the child's bottom margin does not collapse
>>   |     with a top margin that has clearance.
>
> These aren't quite correct in the terminology of CSS, since it
> doesn't consider text to be siblings.  So this is saying that the
> margins of the div and the p collapse in:
>    <div>  text<p>text</p>  text</div>
> (This is an existing problem in the text.)

This section should be all about boxes, not elements, and there's
definitely a block box (and an inline box) wrapped around those
bits of text outside the <p>. So let me change those elements to
boxes to clarify, and I think that should fix the problem ...

> The second one also needs to be adjusted to match the height changes
> above.  The existing text was part of the area where the current
> spec breaks transitivity of adjoining-ness.

If this is part of the substantive change, I'm going to skip it in
this round.

>> [...]
>
>>   | If there are no positive margins, the absolute maximum of the negative
>>   | adjoining margins is deducted from zero.
>
> "absolute maximum of the negative adjoining margins" should instead
> be "maximum of the absolute values of the adjoining margins".  (I
> realize this was existing text, but it's currently wrong.)

Fixed.

Filed LC Issue 211 for your min-height transitivity thing.
   http://wiki.csswg.org/spec/css2.1/last-call-2010#issue-211

~fantasai

Received on Wednesday, 15 September 2010 08:35:23 UTC