W3C home > Mailing lists > Public > www-style@w3.org > February 2012

[CSS21] Errata - proposals for review - Margin collapsing, I

From: Anton Prowse <prowse@moonhenge.net>
Date: Wed, 22 Feb 2012 22:04:07 +0100
Message-ID: <4F455847.6000303@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
The following issues were captured for consideration for CSS21 Errata. I 
propose some wording to resolve the issues, and invite comments on the 
suggestions. Please reply on-list and not in the bug reports themselves; 
thanks!


==================

Bug 16049 - Margin collapsing: clarification needed to Note in 10.7 
(min-height and max-height)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16049


Description:

At the F2F in Paris 2012 
[http://lists.w3.org/Archives/Public/www-style/2012Feb/0529.html] there 
was a discussion about the note in 10.7 (min-height and max-height) 
which appears immediately after the algorithm describing the calculation 
of a tentative height and then used height (based on min-height and 
max-height).  The Note says:

   # These steps do not affect the real computed values of the above
   # properties. The change of used 'height' has no effect on margin
   # collapsing except as specifically required by rules for 'min-height'
   # or 'max-height' in "Collapsing margins" (8.3.1).

There was strong agreement that the second sentence is intended to mean 
that you determine whether and which margins collapse during the 
calculation of the tentative height, and that information remains fixed 
during any recalculation of the used height based on the values of 
min-height and max-height.  That is, you don't recompute anything with 
respect to margin collapsing.

I feel that this is not clearly captured by the Note.

Additionally, the mention of 'max-height' is confusing since there are 
no longer any rules concerning 'max-height' in 8.3.1 (since the spec 
changed a while ago, removing any special consideration of 'max-height').


Proposal:

Replace:

   # These steps do not affect the real computed values of the above
   # properties. The change of used 'height' has no effect on margin
   # collapsing except as specifically required by rules for
   # 'min-height' or 'max-height' in "Collapsing margins" (8.3.1).

with:

   | These steps do not affect the real computed values of the above
   | properties. The change of used 'height' has no effect on margin
   | collapsing; the real computed value of 'height' is used to
   | determine which margins are adjoining in "Collapsing margins"
   | (8.3.1) during these steps.


===================

Bug 16036 - Margin collapsing: pathological collapsing behaviour for 
auto-height, non-zero min-height elements with self-collapsing child 
(Issue 211)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16036

This is Issue 211 from the pre-REC issues list: 
http://wiki.csswg.org/spec/css2.1#issue-211


Description:

The 2010-12-07 WD 
(http://www.w3.org/TR/2010/WD-CSS2-20101207/box.html#collapsing-margins) 
and some previous CRs contained an internal contradiction in the case of 
an auto-height, non-zero min-height element with a single 
self-collapsing child. Section 8.3.1 said:

   % The bottom margin of an in-flow block box with a 'height' of 'auto'
   % is adjoining to its last in-flow block-level child's bottom margin
   % if the element has no bottom padding or border.
   %
   % An element's own margins are adjoining 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) are adjoining.

The former paragraph says that the parent's bottom margin adjoins the 
child's bottom margin (which adjoins its own top margin which adjoins 
the parent's top margin [via other rules not quoted here]).  Yet the 
latter paragraph doesn't cover the case in question (since min-height is 
non-zero) and so the implication is that that the parent's top and 
bottom margin are /not/ adjoining; this was either a contradiction (if 
one believes that adjointness was implicitly transitive) or else it was 
the exact same problem that the current spec, with its new wording and 
terminology, now explicitly suffers from:

In the current spec, 8.3.1 (Collapsing margins) says:

   # Adjoining vertical margins collapse, except [omitted special cases]
   # [...]
   #
   # Two margins are adjoining if and only if:
   # [omitted conditions]
   # * 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
   #   [omitted pair]
   #   - 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
   #
   # A collapsed margin is considered adjoining to another margin if any
   # of its component margins is adjoining to that margin.

So in the case being discussed, the parent's bottom margin adjoins the 
child's bottom margin, which adjoins its own top margin which adjoins 
the parent's top margin... and whilst this does not result in a 
contradiction, it simply means that all margins explicitly collapse 
together, a pathological behaviour given that the parent has non-zero 
used height.


Comment:

At the F2F in Paris 2012 
[http://lists.w3.org/Archives/Public/www-style/2012Feb/0529.html] it was 
tentatively decided to prevent collapsing in the case described.


Proposal:

Replace:

   #   - bottom margin of a last in-flow child and bottom margin of its
   #     parent if the parent has 'auto' computed height

with:

   |   - bottom margin of a last in-flow child and bottom margin of its
   |     parent if the parent has 'auto' computed height and either the
   |     parent has a zero computed min-height or the bottom margin of
   |     the last in-flow child does not collapse with the top margin of
   |     the parent


====================

Bug 16037 - Margin collapsing: unintuitive collapsing between last child 
and auto-height, large min-height parent
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16037


Description:

An auto-height parent box typically collapses its bottom margin with 
that of its last in-flow child, even when the parent has a non-zero 
min-height and even when that min-height is easily large enough to 
"contain" the last in-flow child's bottom margin.  (The background 
behind this choice of behaviour is described in detail in the bug 
report; at the F2F in Paris 2012, the WG expressed a desire not to 
change this behaviour.)

However, this behaviour is not well captured by the Note in 8.3.1 that 
describes the consequences of the margin collapsing rules:

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

The clause "and a 'min-height' of zero" makes the conditions overly 
specific, leading one to think (incorrectly) that collapsing might not 
occur with broader conditions.  This creates confusion.


Proposal:

Assuming that the proposal is accepted for the previous issue described 
above in this post, the the proposal for this issue is to replace:

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

with:

   | The bottom margin of an in-flow block box with a 'height' of 'auto'
   | 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 neither collapses with a top margin that has clearance
   | nor (if the box's min-height is non-zero) with the box's top margin.


(If the proposal for the previous issue is not accepted, then a 
tentative proposal for this issue would be to remove the clause "and a 
'min-height' of zero"; but the previous issue would instead need to be 
resolved in some other way, which would probably have a knock-on effect 
to this issue in any case.)


=====================

Bug 16072 - Margin collapsing: clarification needed as to where a 
collapsed margin manifests itself


Description:

As described in the previous issue, an auto-height parent box typically 
collapses its bottom margin with that of its last in-flow child, even 
when the parent has a non-zero min-height that is large enough to 
"contain" the last in-flow child's bottom margin.  However, nothing in 
the spec indicates where this collapsed margin should manifest itself. 
(See also Bug 15894 - Position of top content edge of non-replaced 
block-level elements is not clearly 
defined.[https://www.w3.org/Bugs/Public/show_bug.cgi?id=15894])

This problem has always existed in full generality, but in most cases 
it's intuitive that the collapsed margin should manifest itself outside 
the parent's border box.  However, in the specific case just described, 
it's less intuitive since one could argue that the collapsed margin 
might manifest itself immediately outside the /child's/ border box, for 
example.


Comment:

It was generally agreed in the F2F in Paris 2012 
[http://lists.w3.org/Archives/Public/www-style/2012Feb/0529.html] that 
the collapsed margin should manifest itself outside the parent's border box.


Proposal:

In 9.4.1, in the following paragraph:

   # In a block formatting context, boxes are laid out one after the
   # other, vertically, beginning at the top of a containing block. The
   # vertical distance between two sibling boxes is determined by the
   # 'margin' properties. Vertical margins between adjacent block-level
   # boxes in a block formatting context collapse.

change the last sentence as follows:

   | Vertical margins between adjacent block-level boxes in a block
   | formatting context <ins>typically</ins> collapse<ins>, and the
   | collapsed margin manifests itself outside of the border areas of
   | all the boxes that have precisely one margin which participates in
   | the collapsed margin</ins>.


[Note that it's not true in general that a collapsed margin lump lies 
outside of the (zero-height) border box of self-collapsing elements.  I 
added the word "typically" because there are clearly various cases where 
margins don't collapse.]


====================


Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Wednesday, 22 February 2012 21:04:36 GMT

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