Bugzilla

From a dataloss perspective, my instinct is that we should generally push monolithic flex items to the start of the next flex-container-fragment, when they run off the bottom of the current fragment (and aren't at the top of that fragment).

I think this is what we do in block layout, and it's a pretty important principle to avoid dataloss in printed output (though I suppose it's somewhat-less-important these days now that we have our fragmentation-fallback codepath which makes monolithic things sort-of fragmentable).

So in testcase 4, this principle would mean that we *should* push the flex item to the next column, effectively stealing some extra packing space for it.

I think this does raise an interesting question for how to handle that packing-space-theft.  If we've got a fragmented fixed-height flex container, and we think we've got 100px (or whatever) of packing space and we distribute it globally along the lines of https://github.com/w3c/csswg-drafts/issues/6812 , and then we find that we have to push a monolithic flex item and "steal" some extra packing space in an early fragment, then we might inadvertently distribute more packing space in later fragments (from our early "global" distribution) than we actually end up having left over, after accounting for the fact that we've had to push flex items.

From a dataloss perspective, my instinct is that we should generally push monolithic flex items to the start of the next flex-container-fragment, when they run off the bottom of the current fragment (if they aren't already at the top of the current fragment).

I think this is what we do in block layout, and it's a pretty important principle to avoid dataloss in printed output (though I suppose it's somewhat-less-important these days now that we have our fragmentation-fallback codepath which makes monolithic things sort-of fragmentable).

So in testcase 4, this principle would mean that we *should* push the flex item to the next column, effectively stealing some extra packing space for it.

I think this does raise an interesting question for how to handle that packing-space-theft.  If we've got a fragmented fixed-height flex container, and we think we've got 100px (or whatever) of packing space and we distribute it globally along the lines of https://github.com/w3c/csswg-drafts/issues/6812 , and then we find that we have to push a monolithic flex item and "steal" some extra packing space in an early fragment, then we might inadvertently distribute more packing space in later fragments (from our early "global" distribution) than we actually end up having left over, after accounting for the fact that we've had to push flex items.