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

Anton,

I like your proposals; I think they capture the essence of what the majority of browsers do. However, I think the wording is a little complicated and can be simplified for readability.

I have listed out below 3 proposals, 2 proposals match one set of implementations and 1 proposal matches 1 implementation. Proposal 1 is your proposal, as is. Proposal 2 is an edited (for clarity) version of your proposal (hopefully with no logic differences, I tried to catch them all). Proposal 3 is an alternate proposal that matches the single other implementation. I have called out some Pros and Cons for each of the proposals to help resolve on these issues. I hope this will help move these issues along.

On Wednesday, February 22, 2012 1:04 PM Anton Prowse wrote:
> 
> ==================
> 
> 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.)
> 

So I believe the bugs (16049, 16036, 16037) above are very interrelated.

There seem to only be 2 test cases that are testing this functionality in the test suite:
http://test.csswg.org/suites/css2.1/20110323/html4/margin-collapse-025.htm

http://test.csswg.org/suites/css2.1/20110323/html4/margin-collapse-037.htm


Depending on the resolution of these proposals the following case needs to correct its pass conditions and probably added to the test suite.
http://test.csswg.org/source/contributors/microsoft/incoming/CSS2.1/margin-padding-clear/margin-collapse-167.htm


-----------------------------------
Proposal 1 (Anton's current proposals)

=Bug 16049=
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=
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=
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.

Pros:
- Matches the functionality of Webkit, Opera and Internet Explorer
- No current CSS 2.1 test cases affected

Cons:
- Does not match Firefox
- Is not consistent with how authors think min-height and height work together
- Mixes concepts of margin collapsing and adjacency in the updated text
- Complicated to read and understand

-----------------------------------
Proposal 2:
This proposal keeps the logic of "Proposal 1" the same but separates the concepts of collapsing and adjacency which we are trying to do in the spec. This also simplifies some of the working to make the topics easier to read without sacrificing necessary logic.

=Bug 16049=
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. 

=Bug 16036=
Replace:
    #   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

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

Add a new bullet to: 
"Adjoining vertical margins collapse, except:"
   | - The top and bottom margins, of a box with a 'min-height' value that
   |    does not compute to zero, do not collapse. If the bottom margin, of such
   |    a box's last inflow-child, collapses with the box's top margin then the
   |    last inflow-child's bottom margin does not collapse with its parent
   |    box's bottom margin.

=Bug 16037=
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.

This proposal I think work better written as a list of sub-bullets.

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.

Pros:
- Matches the functionality of Webkit, Opera and Internet Explorer
- No current CSS 2.1 test cases affected
- Adjacency and margin collapsing are still separate sections within margin collapsing's normative text
- Much easier to read and understand

Cons:
- Does not match Firefox
- Is not consistent with how authors think min-height and height work together

-----------------------------------
Proposal 3
This proposal is more in line with what I can gather Firefox does. I hope I have captured the correct proposal here. I think it's close but in my opinion if we are going for the proposal with the most interop then this proposal might not be worth discussing.

=Bug 16049=
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.

=Bug 16036=
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 the
   |     parent has a computed min-height that is less than or equal 
   |     to the parent's used height

=Bug 16037=
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'
   |   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
   |        - the box has no bottom border, and
   |        - the child's bottom margin does not collapse with a top margin 
   |           that has clearance

Pros:
- Matches the functionality of Firefox
- More consistent with how authors think min-height and height work together
- Adjacency and margin collapsing are still separate sections within margin collapsing's normative text
- Much easier to read and understand
- No current CSS 2.1 test cases affected

Cons:
- Does not match Webkit, Opera and Internet Explorer

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

I would like to handle this issue as a separately from the other issues above and I will send a separate email addressing this issue.

Received on Thursday, 23 February 2012 19:44:58 UTC