[css-break] monolithic-overflow-00[12].tentative.html are wrong

[fantasai]

I think the tests named monolithic-overflow-001.tentative.html and monolithic-overflow-002.tentative.html (there are several of them) are wrong. They assume that a monolithic box cannot be split across columns and must therefore overflow them, but in fact they can be split -- they can't be "fragmented" at a proper break point, but the UA is allowed to slice them so that they don't overflow the fragmentation container.

Finally, if there are no possible break points below the top of the fragmentainer, and not all the content fits, the UA may break anywhere in order to avoid losing content off the edge of the fragmentainer. In such cases, the UA may also fragment the contents of monolithic elements by slicing the element’s graphical representation.

Commit that added them: a2c3d90

[mstensho]

Would be great with some spec clarification and interop here. Chrome and Firefox treat monolithic content inside multicol like that, by overflowing the fragmentainers. Safari slices (Chrome also used to do that, prior to LayoutNG). The same obviously isn't practical when fragmenting for printing, though, so there we slice.

What does "avoid losing content off the edge of the fragmentainer" mean? Yes, it ends up off the edge of the fragmentainer, but the content is not lost. I can see it.

[mafernandez685-eng]

#55152

[fantasai]

I think the current spec is pretty clear that the slicing behavior is allowed. And I'm not inclined to disallow it either, since the content could very well be clipped by a fixed-height container. Multicol is often used to simulate paged content, so this is not even that theoretical of a concern.

[mstensho]

The spec is clear that slicing is allowed, but not that it's mandatory.

So, there's WebKit on one side, which slices, and then there's Firefox and Chrome on the other side, which overflow:

<div style="columns:3; width:500px; column-fill:auto; height:100px; background:yellow;">
  <div style="float:left; position:relative; top:50px; width:50px; height:150px; background:hotpink;"></div>
  <div style="float:right; transform:translateY(20px) rotate(15deg); width:50px; height:150px; background:cyan;"></div>
  <div style="float:left; clear:left; width:60px; height:50px; background:blue;"></div>
</div>

Safari:

Firefox / Chrome:

About the rendering in Safari: Safari additionally appears to still clip at column gaps. That's something that was removed from the spec at some point. Then there's https://drafts.csswg.org/css-break/#transforms which says that "[f]ragmentation interacts with layout, and thus occurs before relative positioning [CSS2], transforms [CSS3-TRANSFORMS], and any other graphical effects.". Safari seems to do it the other way around: first apply such effects, then perform fragmentation. This is similar to what the legacy layout engine (the one originating from WebKit) in Chrome did.

With proper slicing, the two fragmentainers should look like this (modified testcase taken with Chrome in print mode, which enables slicing):

So Safari has bugs, but that's not really interesting for the discussion. Should there be a way to define this behavior? Are Firefox / Chrome wrong? Being able to overflow sure sounds useful though...