[css-overflow-4] Unexpected behavior of `continue: discard` on multicolumn containers with spanners

[andreubotella]

The definition of continue: discard in css-overflow-4, section 5.3 (not the one in appendix A) says that, for a multicolumn container, overflow columns are discarded, which is to say they are not laid out or painted.

Consider the following case, though:

.multicol {
  columns: 3;
  continue: discard;
}
.multicol p {
  break-after: column;
  break-inside: avoid;
}
.spanner {
  column-span: all;
}

<div class="multicol">
  <p>Column 1</p>
  <p>Column 2</p>
  <p>Column 3</p>
  <p>Overflow column</p>
  <div class="spanner">Spanner</div>
</div>

In the case of block containers, or of region breaks in a multicolumn container, continue: discard will discard the remainder of the container, which can be done in implementations by stopping layout at the end of a fragment. However, with overflow columns before a spanner, the layout must resume at the spanner.

My understanding is that the layout at the spanner, and at any further multicol lines after it, is independent from the layout the overflow columns would have, so there is no actual contradiction. I think this could be implemented correctly by having multicol line boxes in the box tree that would end before a spanner, such that only the remainder of the line box would be discarded:

MulticolBox
  MulticolLineBox
    BlockBox ("Column 1")
    BlockBox ("Column 2")
    BlockBox ("Column 3")
    BlockBox ("Overflow column")
  MulticolSpanner
  MulticolLineBox
    ...

But this would be unexpected behavior all the same, since in terms of the DOM tree there would be a range that is skipped by layout. And Chromium's LayoutNG implementation of multicol, at the very least, doesn't use multicol line boxes – it instead treats spanners as forcing a break in the multicol line.

cc @frivoal @bfgeek

[frivoal]

Interesting question.

the layout must resume at the spanner.

I am not sure. The spanner is taken out of flow, and so you could put it back in the multicol, but it's static position is in the overflow columns, which are discarded, so maybe it should be discarded too.

If I understand you correctly, I agree:

• From a layout point of view, I think it would be doable to not discard it, and just place it below the content of the first multi-col line, whose height is only affected by the content in the non discarded columns. That seems fine.

• But from a semantic and content point of view, it could be very strange to have the beginning of the content, drop the middle because it's overflowing, but keep some later part if it is a spanner.

I don't think the spec is really clear at the moment, and you could probably interpret it either way, but I would suggest defining it so that spanners whose static position is in the overflow columns are discarded when continue: discard is applied.

cc: @fantasai

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-4] Unexpected behavior of `continue: discard` on multicolumn containers with spanners, and agreed to the following:

• RESOLVED: if there are overflow columns in a continue:discard element, any content starting with the the first overflow column is discarded

The full IRC log of that discussion

<TabAtkins> andreubotella: i opened this when i was working on continue:collapse
<TabAtkins> andreubotella: continue:discard can be applied to block containers, and also multicol
<TabAtkins> andreubotella: if you have overflow columns, you can have content after those columns; continue:discard is meant to discard the contents of a fragment
<TabAtkins> andreubotella: for some impls, they could just do the whole layout and discard the fragment, but hope is that in browsers that can do fragmentation during layout (chromium does this, webkit is transitioning to this), you could stop the layout just before the discarded part
<TabAtkins> andreubotella: if you have a spanner you'll resume the layout, and ther's content from the overflow columns that can affect the layout of things, like counters
<florian> q+
<TabAtkins> fantasai: so you're saying there's a break after column 3 in the text, then the overflow column...
<TabAtkins> andreubotella: for continue:discard, it's possible to ipmlement by laying out the whole thing then throwing away the excess, but for line-clamp the hope is that you can actually stop the layout at the clamp point
<astearns> ack florian
<TabAtkins> florian: there's a bunch of things you could do, but many dont' make sense. the general idea is continue:discard on an overflow discard the overflow columns... a spanner rooted in those columns gets discarded too
<TabAtkins> florian: if we let the spanner exist it would create weird content, you'd miss the content between the break point and the spanner
<TabAtkins> fantasai: right, once you get to the discard point all further content is discarded
<TabAtkins> andreubotella: i think that's consistent with a multicol in fragmented content and you just discard stuff after the first fragment
<TabAtkins> alisonmaher: does this mean you'll have to keep laying things out?
<TabAtkins> andreubotella: i don't think so. the moment you know there are columns that would overflow, you stop layout for them
<TabAtkins> astearns: so, proposal?
<TabAtkins> andreubotella: if there are overflow columns in a continue:discard element, any content after the first overflow column is discarded
<TabAtkins> s/after the/beginning with the/
<TabAtkins> RESOLVED: if there are overflow columns in a continue:discard element, any content starting with the the first overflow column is discarded

[rachelandrew]

@mstensho flagging this one for you, which is in the Overflow spec but relates to multicol.

[mstensho]

I'd like to take a step back and ask why we want any special behavior at all for columns that overflow in the inline direction. Seems to me that continue is a means of controlling block overflow, in particular so that we get rid of content that would only partially fit at the bottom of a container (e.g. half of a line), which is why we introduce fragmentation here, so that we can handle monolithic content correctly. (Otherwise, overflow:clip would do, right?)

If we want this special behavior for columns that overflow in the inline direction, then why not for flex items as well? Or grids, or floats, or anything that overflows in the inline direction? What's special about columns?

[frivoal]

@mstensho to me, overflow columns are not quite inline overflow: they are indeed placed in the inline direction (css-columns-2 aside), but they are created based on content that would otherwise overflow in the block direction. It only doesn't because we fragment.

Since continue: discard is a way to deal with content that would fragment in the block direction, that makes this applicable here, regardless of whether this overflowing content would otherwise be placed.