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

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

From: Anton Prowse <prowse@moonhenge.net>
Date: Sat, 03 Mar 2012 19:07:51 +0100
Message-ID: <4F525DF7.90306@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
CC: Arron Eicholz <Arron.Eicholz@microsoft.com>
Arron and I have discussed these issues off-list, so I'll merely 
summarize briefly what we discussed and then I'll post a proposal 
(separately in my next post, for ease of reference) that represents our 
current thinking.

On 28/02/2012 01:15, Arron Eicholz wrote:
> On Monday, February 27, 2012 12:52 PM Anton Prowse wrote:
>> On 23/02/2012 20:44, Arron Eicholz wrote:

>>> =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.
>>
>> I agree that removing the clause is better than leaving the current one in
>> place, but for me the problem is that I don't find it clear what the second
>> sentence actually means; that's why I added an explicit explanation in
>> Proposal 1 above.  Perhaps I just have a mental block about it, since others
>> seem not to have a problem with it!
>>
>> I believe the sentence is trying to reinforce the following subtle
>> point: in steps 2 and 3, we are not performing entire layout again with a
>> different /computed/ value of 'height' (which would affect the margin
>> collapsing relationships, and could potentially affect other aspects of layout
>> as well since most layout rules throughout the spec revolve around
>> computed value - although I don't think there actually are any other aspect
>> that would be affected in CSS21).  Instead, we are just performing the rules
>> of, specifically, 10.6 again with a substituted computed value of 'height',
>> which might result in different used values of 'margin-top', 'margin-bottom',
>> 'top' and 'bottom' but nothing else AFAICT.
>>
>> Technically the sentence isn't needed; it's just a Note, after all.  But I do think
>> that some sort of comment is useful.  Perhaps the problem I have with the
>> current formulation is that it says "change of used 'height'", but it's not the
>> used height that's actually changing; the used height is the final outcome
>> after three calculations.
>>
>> How about:
>>
>>     | These steps do not affect the real computed values of the above
>>     | properties. _Collapsed margins_<link to 8.3.1>  remain unchanged
>>     | for each step, since the real computed value of 'height' is used
>>     | when determining which margins collapse.
>>
>
> It's funny the more we work on this particular bug the more I think
> we  just shouldn't say anything about margin collapsing here. Margin
> collapsing explicitly uses the term 'computed' value all throughout
> the margin collapsing section. That means that restating it in the
> min/max-height section makes it unnecessary and somewhat confusing.
>
> We could simplify this by just saying:
> Option 1 (super simple)
> | These steps do not affect the computed values of the above properties.
>
> This would simplify things greatly and eliminate the connection to
> margin collapsing that really isn't there in any way because
> min/max-height do not affect computed values. If we want to tie margin
> collapsing with this note then I think we should just say, "See Margin
> collapsing (8.3.1) on how these properties may interact with the
> margin collapsing model."
>
> Option 2 (simple and passing off to margin collapsing)
> | These steps do not affect the computed values of the above properties.
> | See Margin collapsing (8.3.1) on how these properties may interact with the
> | margin collapsing model.
>
> If we keep it simple or just say go look at margin collapsing then
> we  break up the complication and confusion and put the ownership of
> the explanation in one place where it can be complete and not
> disjointed across different sections of the spec.

We both preferred Option 1.

> I also removed the word 'real' since 'real computed values' isn't a
> defined term.

I felt that 'real' was useful since without it the spec sounds rather odd:

   # [...] but this time using the value of 'min-height' as the
   # computed value for 'height'.
   #
   # These steps do not affect the computed values of the above
   # properties.

We agreed that it's clear what is meant and why the word is there 
(namely that it reinforces the fact that the substitution of the 
computed value of 'height' in steps 2 and 3 is merely a temporary device 
for a particular calculation).  The fact that it's in a Note means that 
its somewhat less important that it isn't a formally defined term.

Arron was on the fence about leaving it in, but said he could live with it.


We discussed a further proposal: "the above properties" is unclear; I 
don't actually know which set of properties it's referring to but we 
guess it's probably 'min-height', 'max-height' and 'height'.  Given that 
there's nothing in 10.7 that could seem to raise doubts about the 
computed values of 'min-height' and 'max-height', we propose
s/the above properties/'height'.

>>
>>> =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.
>>
>> I agree with your observation that my proposal uses the concept of margin
>> collapsing in the specification of adjacency, and that in fact it would be better
>> to keep them separated.
>>
>> However, it seems rather perverse to define two margins as adjoining which
>> intuitively aren't, only to then immediately prevent them from collapsing.
>>
> It is a little strange but we already do it with other rules.
> Specifically the 'except' rules all may contradict the collapse of
> margins that are adjoining.


It's not quite the same situation with other rules, since in those cases 
adjoining margins "usually" collapse but with special exceptions due to 
special conditions (BFC, clearance).  In this proposal, a 
zero/auto-height box with positive min-height never collapses its top 
and bottom margins, which raises the question of why they should be made 
adjoining in the first place.

> I think what really needs to happen is we have to flip the order of
> the 2 sections. The "Two margins are adjoining if and only if:" should
> come first and the "Adjoining margins collapse, except:" section
> should come next. Just switch the order.

This could be useful, and I will file it as a separate bug.

>> How do you feel about the following alternative:
>>
>> Do not modify:
>>     #   - bottom margin of a last in-flow child and bottom margin of its
>>     #     parent if the parent has 'auto' computed height
>>
> I believe you meant rule 4 not rule 3?
>
>> but add a new bullet to:
>>     # "Adjoining vertical margins collapse, except:"
>>
>>     | - If the top margin of a box with non-zero computed 'min-height'
>>     |   and 'auto' computed 'height' collapses with the bottom margin of
>>     |   its last in-flow child, then the child's bottom margin does not
>>     |   collapse with the parent's bottom margin.
>>
>
> I still think this is incorrect and why my last proposal covered
> what  it did. Let me explain.
>
> Let A and D be 2 adjoining margins. Let us add a box with adjoining
> top and bottom margins, B and C, between A and D.
>
> It seems inconsistent that adding the adjoining margins of B and C
> would break the transitive adjacency of A and D.
>
> I think it is better to have adjacency rules consistent and have the
> 'collapse except rules' cause lack of collapse in this scenario, than
> have the inconsistent adjacency rules enforce the lack of collapse.

Adjointness is not transitive, so this counter-argument doesn't apply.

Arron and I discussed how both proposals work and achieve the same 
thing.  In the end we settled on my alternative above.

>>> =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.
>>
>> I completely agree here.  The sentence was already hard to read, and with
>> the extra clause it becomes downright convoluted.  The list approach works
>> better.
>
> Great, so I think we have this bug solved since we both agree.

Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Saturday, 3 March 2012 18:08:22 GMT

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