Re: [csswg-drafts] [css-contain-2] contain:size shouldn't fragment as monolithic (#5648)

So, while this issue is handled (by deferring it) for L1, in L2 and later, we could relax the requirement a little.

Currently, we have:
> [Size containment boxes](https://www.w3.org/TR/css-contain-2/#size-containment-box) are [monolithic](https://www.w3.org/TR/css-break-3/#monolithic)

I believe we could replace that with:

> [Size containment boxes](https://www.w3.org/TR/css-contain-2/#size-containment-box) are [quasi-monolithic](https://www.w3.org/TR/css-break-3/#monolithic)

and define quasi-monolithic boxes as something like:
> Quasi-monolithic boxes are similar to monolithic boxes:
> * forced breaks within a quasi-monolithic box must be ignored by the box’s own fragmentation context
> * quasi-monolithic boxes should not be fragmented
> * if a quasi-monolithic box needs to be fragmented, the box is sliced at a point which does not depend on the box's content, only on its size and its position within its fragmentation context.
>
> However, unlike monolithic boxes, when a quasi-monolithic box is thus broken up, its <em>content</em> may be fragmented and laid out normally within each of the fragments instead of being graphically sliced—although graphically slicing is also allowed.

We could obviously do the same thing without introducing the new term and inlining the effects into size containment, but I suspect it's easier to read if framed this way.

And maybe (but that's not essential to the proposal here) this would also allow the CSS Fragmentation Module to change from "may consider as monolithic" to "may consider as quasi-monolithic" when talking about `overflow: hidden` boxes and the like.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5648#issuecomment-1240067326 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 8 September 2022 00:47:58 UTC