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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3