- From: Alison Maher via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Dec 2021 22:03:56 +0000
- To: public-css-archive@w3.org
alisonmaher has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-flexbox] Multi-line column flexbox fragmentation == As noted in the [sample algorithm](https://drafts.csswg.org/css-flexbox/#pagination-algo) 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](https://drafts.csswg.org/css-flexbox/#pagination) 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. cc @mstensho @bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6855 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 3 December 2021 22:03:58 UTC