Description
As noted in the sample algorithm for multi-line column flex containers:
If a flex item does not entirely fit on a single page, it will not be paginated in multi-line column flex containers.
Why are items in a multi-line column flex container suggested to be treated as monolithic while the other algorithms do not? For example, shouldn't a fragmented multi-line column flex container with one column behave the same as a fragmented single-line column flex container?
The flex fragmentation spec also mentions:
When a multi-line column flex container breaks, each fragment has its own "stack" of flex lines, just like each fragment of a multi-column container has its own row of column boxes.
To me, this almost implies that a multi-line column flex container will act as a fragmentation context (expect for the fact that items are considered monolithic, as mentioned above). Does it make sense to do the same thing here as a nested multi-column? If we were to instead fragment each flexbox column independently, when stitched back together, the columns would match more closely to the unfragmented result.
Note: neither Gecko or Chromium's implementations of multi-line column flex fragmentation are currently following either of these points in the spec.