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

> what we want to say is that the box is treated as fixed-size for the purposes of fragmentation (it cannot get larger, only split across pages)

Well, yes we mean that, but also:
* that you should avoid fragmenting them if possible (see below for why)
* and if you do fragment them, the point at which the box is split should not depend on the layout of its content. The size of each fragment should only depend on the size and position of the box, not what's in it.

As long as that's respected, when we do fragment, we don't have to visually slice the content, and we could break it cleanly between lines or at otherwise allowed fragmentation points. However, both are kind of bad (which is why we should avoid fragmenting in the first place when possible), so I'd be inclined to let that up to the UA though: If the box is more than tall enough to fit all its content, it's best to do fragmentation of the content cleanly. But this might underfill the first(s) fragments, and put too much content in the last one. If that last fragment isn't tall enough to accommodate all that's pushed into it, it might be ok to let it overflow, or it might have been better to slice the content instead of fragmenting it cleanly if that would avoid overflow.

For instance, if the unfragmented box is just tall enough to fit 3 lines, and it gets fragmented in 2 equal parts, you can either put 1 line in the first and 2 in the second letting that last line overflow (and possibly overlap with subsequent content), or you can put 1.5 lines in each. Both seem bad, so I'm not sure I want to force UA's hand.

So, overall, I think calling them monolithic is the right call, but we might want to add an allowance UA discretion about how they slice or fragment the contents when they do need to fragment.

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


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

Received on Friday, 23 October 2020 07:12:10 UTC