Re: [CSS2.1] Clarifying 8.3.1 Collapsing Margins

On 22/09/2010 15:42, 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 6.
>
> In 9.4.1 append "for their contents" to "establish a new block
> formatting context".
>
> Rewrite 8.3.1 as:
>
> | In CSS, the adjoining margins of two or more boxes (which might or
> | might not be siblings) can combine to form a single margin.
> | 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.

See [1].

> | Horizontal margins never collapse.
> |
> | Two margins are adjoining if and only if:
> | * both belong to in-flow block-level boxes that participate in
> | the same block formatting context
> | * 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 next in-flow
> | following sibling
> | - bottom margin of a last in-flow child and bottom margin
> | of its parent if the parent has 'auto' computed height

> | - top and bottom margins of a box that does not establish
> | a new block formatting context and that has zero computed
> | 'min-height', zero or 'auto' computed 'height', and no
> | in-flow children

This excludes overflow:hidden boxes, which seems to be a change from the 
current spec.  Is that intentional?

> | A collapsed margin is considered adjoining to another margin if
> | any of its component margins is adjoining to that margin.
> |
> | Note. Adjoining margins can be generated by elements that are not
> | related as siblings or ancestors.
> |
> | Note the above rules imply that:
> | * Vertical margins between a floated box and any other box do not
> | collapse (not even between a float and its in-flow children).
> | * Vertical margins of elements that establish new block formatting
> | contexts (such as floats and elements with 'overflow' other than
> | 'visible') do not collapse with their in-flow children.
> | * Margins of absolutely positioned boxes do not collapse (not even
> | with their in-flow children).
> | * Margins of inline-block boxes do not collapse (not even with
> | their in-flow children).

> | * The bottom margin of an in-flow block-level element always
> | collapses with the top margin of its next in-flow block-level
> | sibling, unless that sibling has clearance.
> | * 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.

Element vs box again.  Can we express these two items in terms of boxes 
to match all the other items in this list?

> | * The bottom margin of an in-flow block box with a 'height' of
> | 'auto' and a 'min-height' of zero collapses with its last in-flow
> | block-level child's bottom margin if the box has no bottom padding
> | and no bottom border and the child's bottom margin does not
> | collapse with a top margin that has clearance.

See [1].

> | * A box's own margins collapse if the 'min-height' property
> | is zero, and it has neither top or bottom borders nor top or
> | bottom padding, and it has a 'height' of either 0 or 'auto', and
> | it does not contain a line box, and all of its in-flow children's
> | margins (if any) collapse.

This is not true any more.  In particular, in the following test case,

<div style="margin:10px 0; height:0">
	<div style="margin:10px 0"></div>
</div>

the parent's margins don't collapse according to the earlier rules 
concerning adjacency since the bottom margin of the child is not 
adjacent to the bottom margin of the parent.  (Specifically, in this 
situation, the child self-collapses and the resulting margin collapses 
with the parent's top margin, but this new resulting margin doesn't 
collapse with the parent's bottom margin.)

[What's the position of the parent's top border?  It's either the same 
as the position of /its/ parent's top border (8.3.1.6.1) or its where it 
would be if the parent had a non-zero bottom border (8.3.1.6.2) which is 
"at the top of" the uncollapsed bottom margin.  This seems to hold 
together sensibly.  But thank goodness for that 2007 spec change of 
8.3.1.6.2!  If the parent's top border position were calculated by 
introducing a temporary non-zero top border instead of a temporary 
non-zero bottom border, as used to be the case, then we'd be in a rather 
strange place with the following test case:

<div style="border-bottom:1px solid"></div>
<div style="margin-bottom:20px">
     <div style="margin:100px 0"></div>
</div>
<div style="border-bottom:1px solid"></div>

There'd be 120px between the two solid lines, the bottom 20px 
unmistakable as the bottom (uncollapsed) margin of the parent, yet the 
position of the parent's top border would be at the top of the 120px 
space.  The moral is, "artificially" preventing collapsing sets traps 
for the unwary!]

Returning to the point in hand, when the box's height is 0 then this 
spec item holds only when the box has no children, whereas when the 
height is 'auto' the item holds as given.

To resolve this, replace:
   | * A box's own margins collapse if the 'min-height' property
   | is zero, and it has neither top or bottom borders nor top or
   | bottom padding, and it has a 'height' of either 0 or 'auto', and
   | it does not contain a line box, and all of its in-flow children's
   | margins (if any) collapse.
with:
   : * A box's own margins collapse if the 'min-height' property
   : is zero, and it has neither top or bottom borders nor top or
   : bottom padding, and it does not contain a line box, and it either
   : has a 'height' of 0 and no in-flow children or it has a height
   : of 'auto' and all of its in-flow children's margins (if any)
   : collapse.

> |
> | When two or more margins collapse, the resulting margin width is the
> | maximum of the collapsing margins' widths. In the case of negative
> | margins, the maximum of the absolute values of the negative adjoining
> | margins is deducted from the maximum of the positive adjoining margins.
> | If there are no positive margins, the maximum of the absolute values
> | of the adjoining margins adjoining margins is deducted from zero.

Delete the duplicated instance of adjoining margins on the last line.

> | If the top and bottom margins of a box are adjoining, then it is
> | possible for margins to collapse through it. In this case, the
> | position of the element depends on its relationship with the other
> | elements whose margins are being collapsed.

s/are adjoining/collapse/
since we need to define the position of a collapsed-through element even 
when its top and bottom margins are not adjoining, which would be when 
it has a (necessarily self-collapsing) child.

> | * If the element's margins are collapsed with its parent's top
> | margin, the top border edge of the box is defined to be the
> | same as the parent's.
> | * Otherwise, either the element's parent is not taking part in
> | the margin collapsing, or only the parent's bottom margin is
> | involved. The position of the element's top border edge is
> | the same as it would have been if the element had a non-zero
> | bottom border.
> | Note that the positions of elements that have been collapsed through
> | have no effect on the positions of the other elements with whose
> | margins they are being collapsed; the top border edge position is
> | only required for laying out descendants of these elements.


[1] http://lists.w3.org/Archives/Public/www-style/2010Aug/0416.html

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

Received on Wednesday, 22 September 2010 19:35:35 UTC