Re: [css3-multicol] should spanner margins collapse?

On 21/11/2011 21:11, Rossen Atanassov wrote:
>> -----Original Message-----
>> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
>> Behalf Of Anton Prowse
>> Sent: Wednesday, October 19, 2011 7:08 AM
>>
>> On 29/09/2011 14:06, Håkon Wium Lie wrote:
>>> The CSS WG is discussing margin collapsing on spanning elements
>>> ("spanners") and would like some feedback. The basic question is:
>>> should margins set on consecutive spanners collapse?
>>>
>>> Consider this markup:
>>>
>>>     <div class=multicol>
>>>        <h1>Heading</h1>
>>>        <h2>Subheading</h2>
>>>        <p>............
>>>     </div>
>>>
>>> And this styling:
>>>
>>>     div.multicol { columns: 10em; border: ... }
>>>     h1, h2 { column-span: all; margin: 1em 0 }
>>>
>>> If the browser doesn't support multicol, margin collapsing would occur
>>> between the h1, h2, and p elements.
>>>
>>> If the browser supports multicol, the content of<p>   will appear in
>>> multiple columns, and the spanners will stretch across. The rendering
>>> could be something like:
>>>
>>>       ___________________________________
>>>      |                                   |
>>>      | Heading                           |
>>>      |                                   |
>>>      | Subheading                        |
>>>      |                                   |
>>>      | ...............   ............... |
>>>      | ...............   ............... |
>>>      | ...............   ............... |
>>>      |___________________________________|
>>>
>>> In the above ascii art, the margins between the h1 an h2 elements have
>>> collapsed.
>>>
>>> A releated issue is how to deal with floats; should floats be able to
>>> cross over from one spanner to the next?
>>>
>>> Thee WG has three possible solutions to this issue. Here's a comparison:
>>>
>>>               Do spanners create BFCs?                MC       XF     MC-c
>>>
>>> (a)         no, but (consecutive) spanners          yes      yes    yes
>>>               with identical column-span value
>>>               are wrapped into one anonymous BFC
>>>
>>> (b)         yes, but the margins of the BFC         no       no     no
>>>               don't collapse (unlike other BFCs)
>>>
>>> (c)         yes, and they collapse as other BFCs    yes      no     no
>>>
>>> where
>>>
>>>     BFC = block formatting context
>>>     MC = margin-collapse between consecutive spanners
>>>     XF = cross floats between consecutive spanners
>>>     MC-c = margin-collaps between consecutive spanners, including
>>> children
>>>
>>> The specification [1] today suggests (c). But it can be changed if,
>>> e.g., XF or MC-c are important to authors. Are they?
>>>
>>> Or, we could do (b) if authors would rather avoid MC/XF in multicol.
>>> One argument in favor of this is: If we add integer values to
>>> 'column-span' in the future, the spanners become more like floats. And
>>> floats don't do MC/XF.
>>
>> Given the primary use case (headings that span all columns) I think we should
>> defer to typical print usage where that use case is quite common.
>>    It appears to me that margins between consecutive spanners /do/ collapse
>> in print contexts.  This would rule out option (b).
>>
>> I don't see much similarity between spanners and floats.  To my mind, a 2-
>> column spanner doesn't behave like a float, because the spanner remains in
>> flow and hence there is no concept of surrounding content breaking around
>> it.  Something that would be more similar to floats would be pull-quotes
>> (where I think I would expect no collapsing with surrounding content) but
>> that's not what spanners are.
>>
>> My preference is (a) because I don't see any reason not to make the
>> behaviour of multicol as close as possible to the CSS21 behaviour, which
>> would aid authors trying to support both modern (multicol-aware) and legacy
>> UAs with the same stylesheet.
>>

>
> Why not option A.
>
> A column spanning element can come from any depth
> of the multicolumn content, say from inside a nested table, flex or
> grid element.

This does indeed seem to be the case according to the spec.

> Being a non-BFC would mean that it belongs to the same
> block formatting context as its visual (but not content) children.
> This sounds like an incomprehensible situation.

Whether or not an element establishes a BFC doesn't alter which BFC it 
participates in, so I don't follow you.  (I believe this is true even 
for abspos elements, although CSS21 is very vague as to the containment 
model of abspos elements.  Note that I'm not talking about containing 
blocks here, whose model is more clearly defined.)

> It would also mean
> that floaters that extend beyond the boundaries of the spanning
> element will affect the following spanning element's content...

This is true... but that's the case with consecutive headings that 
contain a float in the normal block formatting model anyhow.

> Advocating for this option means to only consider the case when the
> column spanning element is an immediate child of multi-column element
> which is a restriction that is not imposed by the current spec (nor
> should it be).

Such an unrestricted model doesn't make much sense to me anyway.  Surely 
only elements which participate in the block formatting context of one 
of the columns should be allowed to span.  What are the use cases for 
allowing spanning from within a nested BFC?  What does it mean for an 
element inside an inline-block or overflow-scroll or floated or abspos 
column content element to span the columns?


> Why not option C.
>
> Margin collapsing only makes sense on a boundary
> between two blocks elements belonging to the same normal flow. Not
> only the column spanning element can appear in the middle of another
> block, but it can even belong to a different normal flow, so that
> margin collapsing would be very "non-local" in such case. The
> spanning element in this respect is more similar to a floater which
> does not participate in margin collapsing.

As above,  I can't see how spanning is supposed to work in such cases. 
With more restricted spanning I don't see this as an argument against 
Option C.

> On the argument that when the multi-column is a single-column, the
> column spanning element looks much like a static block so it should
> behave like static block. Floaters, table cells, flex items, grid
> items and even absolutely positioned elements can all be made to
> "look" like block elements in the normal flow, but this does not make
> them such.

True, but I don't see the relevance.  The desire is to minimize the 
changes in local rendering (around the spanner) when the global 
rendering (the multicol) is not supported by a UA or when the number of 
columns toggles between one and more than one.  None of the types you 
mention would change in their local rendering, whereas spanners would 
with all options, most dramatically with Option B.


> Why option B.
>
> Let's assume that spanning elements always come from
> the normal flow inside column boxes of the multicolumn elements. We
> first need to address how margin collapsing is affected by the column
> boxes themselves. Say there is a column spanning element with a
> non-zero top margin, would the expectation be that its box will be
> equal distance from all previous column boxes?

Yes.

> What if the column
> spanning element comes from the inside of many non-BFC elements that
> also have defined top margins, should we collapse with these elements
> as well?

I think so.  (Although actually this wouldn't happen with Options B or 
(maybe) A.  I find myself leaning more towards Option C now.)

> In my opinion this is what makes spanning elements closer to
> floaters - the immediate expectation is that their margins are used
> to distance them away, equally from all column boxes by the same
> amount.

But that will happen anyway, regardless of which option is chosen.  The 
question is rather whether the top margin of the spanner and the top 
margin of its parent should be treated separately (Option B) or 
collapsed together (Options A and C).  Treating them separately doesn't 
seem so elegant.


However, all this said, I do find myself floating from one option to 
another, with a current preference for Option C.  Option B, however, 
feels "cold" and I'm not yet won over by it; but given that the concept 
of spanners don't really fit into the current CSS formatting models 
anyhow I can see the attraction of making them as "rigid" as possible 
and marking them clearly from their surroundings.

Option A wraps spanners of the same "length" in a single alone BFC root. 
  It doesn't explicitly say so, but I was assuming that if the spanner 
stands alone then it too is wrapped in an anonymous BFC root.  One of 
the differences between this and having each spanner forming a BFC 
itself is that margin collapsing can occur between consecutive spanners 
of the same "length", but conversely it can't occur between consecutive 
spanners of different "length" (since child margins never collapse with 
a BFC root's own margins).  Such spanners don't existing in 
CSS3-multicol but may arise in a future level of multicol, and Option C 
would permit collapsing between them.

I'm looking forward to fantasai's blog post on this spanners topic!


I'm not yet convinced by the multicol design.  I think columns should 
establish BFCs (rather than the multicol element).  On the other hand, 
that would mean cause difficulties with tall floats near to the bottom 
of pages... although that's a flaw in the design of floats rather than 
something specific to multicol.  I think the difficulties we're having 
with defining spanners is at least partly due to deeper difficulties 
with the multicol model itself.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Monday, 28 November 2011 14:20:15 UTC