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

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

Since I expressed my opinion both at TPAC and the last conf call that we should be 

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. 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. It would also mean that floaters that extend beyond the boundaries of the spanning element will affect the following spanning element's content... 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).

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. 

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.

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? 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? 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. Thus, margin collapsing on column spanning elements should be avoided.

Thanks,
Rossen

Received on Monday, 21 November 2011 20:12:14 UTC