- From: Anton Prowse <prowse@moonhenge.net>
- Date: Wed, 22 Feb 2012 22:04:07 +0100
- 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 UTC