[css-multicol] Definition of adjacent spanners, when to create column boxes

[mstensho]

Should "adjacent spanners" be defined in more detail? Here's what we have today:

https://drafts.csswg.org/css-multicol/#spanning-columns

Spanners are block-level boxes therefore the margins of two adjacent spanners will collapse with each other. As column boxes establish a new block formatting context, margins on elements inside a column box will not collapse with the margin of a spanner.

So it looks like a column box between two spanners will prevent them from being adjacent, but when exactly do we create column boxes?

Are #s1 and #s2 adjacent spanners? Not if #abs causes a column box to be created, for sure, but should it? If it shouldn't, should we still treat #s1 and #s2 as adjacent?

Browsers don't agree. Blink and EdgeHTML draw a 100x100 square (i.e. adjacent). Gecko draws a 100x150 rectangle (i.e. not adjacent). Currently the new fragmentation engine that we're working on in Blink behaves like Gecko, but this is merely an outcome of implementation details, and not a conscious choice.

[rachelandrew]

It seems we should definitely make a decision and add something about the abspos case.

I'll agenda+ it. I think my preference would be that if there is an abspos item, it's out of flow and therefore the spanners are adjacent to each other and margins should collapse. That seems like the behavior I'd expect as an author.

Safari is doing what current Chromium does, collapsing the margins.

CodePen: https://codepen.io/rachelandrew/pen/9be69994f15df720cd5b920cfc5d2c10

[dholbert]

Note that margins do collapse in regular block layout, when there's an abspos element separating two adjacent blocks, as shown here:
https://jsfiddle.net/dholbert/46nLusf2/
CSS:

.square-with-margin {
  margin: 50px;
  height: 50px;
  width: 50px;
}
.blue { background: blue; }
.teal { background: teal; }
.abs { position: absolute; }

HTML:

<div class="square-with-margin blue">div>
<div class="abs">hellodiv>
<div class="square-with-margin teal">div>

So at first glance, I think I'd expect the same collapsing behavior from spanners as well.

[mstensho]

Then again, abspos descendants do affect a containing multicol container in special ways; see issue #6279 - abspos descendants affect column balancing in browsers (but should they?).

Should (contained) OOFs trigger creation of column boxes? I suppose that answer would determine whether a spanner before and after should have their margins collapsed.

[aethanyc]

Should (contained) OOFs trigger creation of column boxes? I suppose that answer would determine whether a spanner before and after should have their margins collapsed.

I agree the problem reduces to the above statement. Firefox currently always triggers the creation of column boxes to contain non-column-span elements, whether they are absolutely positioned or not. So in the original example, the margin of #s1 and #s2 not collapsing is just a consequence that there's a column box in between them.

[css-meeting-bot]

The CSS Working Group just discussed [css-multicol] Definition of adjacent spanners, when to create column boxes, and agreed to the following:

• RESOLVED: Confirm that abspos elemetns do not create column boxes and this adjacent spanners sep by abspos will collapse margins

The full IRC log of that discussion

Topic: [css-multicol] Definition of adjacent spanners, when to create column boxes
github: https://github.com//issues/6265
rachelandrew: Couple of linked issue with out of flow items
rachelandrew: I think example is straightforward. Got adjacent spanners that come directly after. margins collapse is in spec
rachelandrew: If you have abspos item inbetween which is taken out of flow we don't have interop. Gecko is not margin collapsing. Keeping abspos item separating. Blink and Safari do collapse
rachelandrew: Morton brought up b/c new fragementation engine doesn't
rachelandrew: What happens if we have out of flow item between 2 column spanners. Happy with margins not collapsing or want them to collapse
yes
astearns: if you have non-spanning elements sep by out of flow do margins collapse?
rachelandrew: um...I'd have to test. Not sure
fantasai: They do collapse
rachelandrew: Cool
dholbert: I posted test case on GH showing they do in the simplified scenario
fantasai: I think this is a little...worth pointing out if you have abspos content contained by a block-level box and you remove the boxes it gets trapped and creates columns.
fantasai: If abspos is directly contained by multicol I don't see that is should cause creation of margin
rachelandrew: That's what I thought. It would mean Gecko changing what they're doing
s/and you remove the boxes/
s/and you remove the boxes//
astearns: fantasai you suggest in case where abspos is contianed by siblining it's different?
q+
ack TYLin
fantasai: If there's an abspos position:releative element it creats column boxes and abspos can cause a height. But it's the block box causing the columns. When it's directly contained no reason to create columns and therefore not effect margins
s/abspos/abspos inside it/
TYLin: Reason why FF is not collapsing margin is b/c when it's out of flow it still leaves placeholder which triggers column box to be created so there is a gap between the adjacent
fantasai: But margin collapsing rules generally ignore abspos leements. So no reason why that should be happening
TYLin: Agree
dholbert: Create the column box to create placeholder. If say abspos placeholder don't get a box that would fix it
fantasai: placeholders only exist in tables.
dholbert: Yeah. Abspos elements don't cause creation of column box. I think that's what you're proposing.
s/tables/table box generation, as far as the specs are concerned. They're otherwise an implementation artifact/
astearns: Sounds like FF is willing to change
astearns: It was said Morton brought this up b/c new generation matched FF
rachelandrew: I don't think it was a concious choice but was impl details. I'm assuming they're happy to go back. We can ask
iank: I didn't get to talk with Morton before meeting. I think we'd be fine with that
s/Morton/Morten/
astearns: prop: Confirm that abspos eleemtns do not create column boxes and this adjacent spanners sep by abspos will collapse margins
fantasai: It hink it's no change
astearns: Clarifications and some tests, I suspect
fantasai: [missed] amrgin collapsing eslewehre might. Need tests
iank_: Don't know if that's correct about don't create column boxes. Might conflict with next issue
iank_: And that issue is basically does column balancing apply when you've only got abspos in multicol
fantasai: Not in conflict b/c columns not being created by abspos in the next issue. Box with position:relative creates it. It might be 0 height and can't see, but it's causing creation of column row
iank_: I guess this sort of gets at...need to think about it
s/[missed]/if we call this out in the spec, that implies that/
astearns: Why don't we resolve adjacent spanners sep by abspos elements will collapse margins
s/Need tests/Need tests, but no change to spec/
astearns: Abspos elements not creating column boxes is probably implied. But we can go with just margin collapsing for now
iank_: Re-read next, I was wrong
astearns: Back to orginal proposal. "Confirm that abspos elemetns do not create column boxes and this adjacent spanners sep by abspos will collapse margins"
RESOLVED: Confirm that abspos elemetns do not create column boxes and this adjacent spanners sep by abspos will collapse margins