This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16037 - Margin collapsing: unintuitive collapsing between last child and auto-height, large min-height parent
Summary: Margin collapsing: unintuitive collapsing between last child and auto-height,...
Status: ASSIGNED
Alias: None
Product: CSS
Classification: Unclassified
Component: CSS Level 2 (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Bert Bos
QA Contact: public-css-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-20 18:46 UTC by Anton P
Modified: 2012-05-21 16:31 UTC (History)
0 users

See Also:


Attachments
testcase (527 bytes, text/html)
2012-05-21 16:31 UTC, Anton P
Details

Description Anton P 2012-02-20 18:46:36 UTC
Reported by Anton Prowse

Issue 79 concerned the fact that people didn't like the discontinuity that arises in earlier versions of the spec when min-height on an auto-height element transitions from having no effect (in which case the element's bottom margin collapses with its last in-flow child's bottom margin) to having an effect (in which case those margins do not collapse): the parent's height is discontinuously increased to enclose the child's margin.  The WG resolved that those margins should collapse even when min-height has an effect. [http://lists.w3.org/Archives/Public/www-style/2008Nov/0473.html]

The motivation behind the resolution was to avoid discontinuities and to avoid the need to define partial margin collapsing (which was positively viewed in general but regarded as too complex a change at that point in the spec's life).  The key test case discussed was when the margin area height of a child with large bottom margin is slightly bigger than the parent's min-height; it was felt that the margins should collapse (matching what would have happened if the parent's min-height had been smaller) rather than have the parent expand its height to contain the child's margin.

However, this results in strange behaviour: when the parent's min-height is easily large enough to "contain" the last in-flow child's bottom margin, collapsing still occurs.  This is unintuitive for authors.

We must decide whether the specified behaviour is still desired.


Issue 79: http://wiki.csswg.org/spec/css2.1#issue-79

URL
    http://lists.w3.org/Archives/Public/www-style/2008Sep/0112.html
Summary
    margin-collapsing with min-height
Proposal
    http://lists.w3.org/Archives/Public/www-style/2008Nov/0297.html
Resolution
    Proposal accepted (telcon 2008-12-10)
Status
    Closed.
Comment 1 Anton P 2012-02-20 19:39:01 UTC
David Baron felt that preventing those margins from collapsing (or at least, making the behaviour undefined) when there is a non-zero min-height might be the way to go, but noted that implementations do fairly consistently collapse those margins. [http://lists.w3.org/Archives/Public/www-style/2010Sep/0451.html , http://lists.w3.org/Archives/Public/www-style/2011Mar/0346.html]

At the F2F in Paris 2012 [http://lists.w3.org/Archives/Public/www-style/2012Feb/0529.html] Alex Mogilevsky argued that implementers have resisted conditional margin collapsing that depends on whether min-height has an effect or not, since all other aspects of margin collapsing can be calculated before layout starts but not this one.  He also argued that we don't want to prevent margin collapsing when min-height didn't take effect (which, quite apart from being undesirable for authors, could also result in cycles since whether or not the min-height has an effect depends on whether or not the parent is expected to contain its child's margin).

The solution would seem to be to always permit collapsing even in the "strange" case.
Comment 2 Anton P 2012-02-20 19:50:13 UTC
PROPOSAL:

Assuming that the above solution is agreed upon, then no change is needed to the normative spec text for the non-zero min-height case, but a change is needed to the Note in 8.3.1:

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

s/and a 'min-height' of zero//
since it misleading to focus on the zero min-height case as if it were the only situation in which there can be collapsing between the margins described.

Note that the phrase in question was introduced [http://lists.w3.org/Archives/Public/www-style/2010Sep/0683.html] in response to David's point described in Comment 1.  I'm not clear that it serves any purpose though, since it's not in the normative text and hence doesn't actually fulfil David's point anyhow.  Instead, it just seems to introduce confusion.
Comment 3 Anton P 2012-02-20 20:21:02 UTC
The proposal in Bug 16036 suggests that another change is needed to the quoted item in Comment 2 above.  The "and a 'min-height' of zero" phrase actually ensures that the item remains correct in the light of the proposal!  However, the argument that it is misleading to focus on one particular case as if it were the only relevant case still stands, so here is an alternative proposal for this bug if the proposal for Bug 16036 is accepted:

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.
Comment 4 Anton P 2012-02-20 21:30:31 UTC
(See also http://lists.w3.org/Archives/Public/www-style/2008Nov/0022.html for more background to the WG resolution described in Commment 1.  Note that the strange behaviour was a known side-effect of the resolution.)
Comment 5 Anton P 2012-04-11 16:05:15 UTC
An updated proposal is: [http://lists.w3.org/Archives/Public/www-style/2012Mar/0052.html]

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
   |      - the box has 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.
Comment 6 Anton P 2012-05-21 16:28:02 UTC
The WG resolved to accept the change proposed in Comment 5 to close this issue.

Minutes of resolution: http://lists.w3.org/Archives/Public/www-style/2012Apr/0276.html
Comment 7 Anton P 2012-05-21 16:31:20 UTC
Created attachment 1133 [details]
testcase