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

The CSS Working Group just discussed `[css-contain-2] contain:size shouldn't fragment as monolithic`.

<details><summary>The full IRC log of that discussion</summary>
&lt;chrishtr> florian: we previously deferred this issue to contain level 2<br>
&lt;chrishtr> florian: idea is that size containment has two requirements: if it has size containment and it's in the context of fragmentation, then you don't want content in the box to change the size of the sum, and not change the size of each fragment<br>
&lt;chrishtr> florian: for the first, it's good enough for it to always have a fixed xed<br>
&lt;chrishtr> florian: size<br>
&lt;chrishtr> florian: however where you fragment and size of fragments depends on the content of this box<br>
&lt;chrishtr> florian: to avoid this problem we defined size containment to force a monolithic behavior<br>
&lt;chrishtr> florian: this suffices, but may be too restrictive<br>
&lt;chrishtr> florian: e.g. if you have a box that is tall enough to have 4 but have 5 and then could have two columns of 2.5, but with monolithic it'd be wasting space?<br>
&lt;chrishtr> florian: suggestion is to introduce a concept "quasi-monolithic" that has most but not all of the concepts of monolithic<br>
&lt;florian> Quasi-monolithic boxes are similar to monolithic boxes:<br>
&lt;florian>     forced breaks within a quasi-monolithic box must be ignored by the box’s own fragmentation context<br>
&lt;florian>     quasi-monolithic boxes should not be fragmented<br>
&lt;florian>     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.<br>
&lt;florian> However, unlike monolithic boxes, when a quasi-monolithic box is thus broken up, its content may be fragmented and laid out normally within each of the fragments instead of being graphically sliced—although graphically slicing is also allowed.<br>
&lt;chrishtr> florian: the difference between quasi-monolithic and monolithic is that you can fragment within the child boxes (?)<br>
&lt;chrishtr> florian: browsers would gain more options for how to spread content, which might be better for printing and multicol readability<br>
&lt;dholbert> q+<br>
&lt;chrishtr> florian: should we allow this new thing in the spec? give up?<br>
&lt;iank_> q+<br>
&lt;chrishtr> dholbert: you mentioned that quasi-monolithic boxes should avoid being fragmented. wondering what that means in the situtation of a quasi-monolithic box of 1/3 page height but it just barely goes off the end, should we move the whole thing to the next page or cut it?<br>
&lt;chrishtr> florian: should avoid fragmenting if possible but some leeway<br>
&lt;chrishtr> florian: don't remember how much leeway there is<br>
&lt;Rossen7> ack dholbert<br>
&lt;chrishtr> iank_: I'd err on the side of keeping it monolithic for now.<br>
&lt;chrishtr> iank_: not hearing strong developer feedback<br>
&lt;chrishtr> iank_: in some cases Chromium is the only implementation that treats break-inside as non-monolithic. advised people to use contain: size for some cases.<br>
&lt;florian> q+<br>
&lt;chrishtr> iank_: prefer no change to spec for now<br>
&lt;Rossen7> ack iank_<br>
&lt;Rossen7> ack florian<br>
&lt;chrishtr> florian: if there is no implementer interest then perhaps we should just close the issue<br>
&lt;miriam> q+<br>
&lt;chrishtr> florian: but wanted to raise this because developers might want that fragmentation, and used container queries and the result was monolithic that could be bad. Maybe better to offer implementation options?<br>
&lt;Rossen7> ack miriam<br>
&lt;chrishtr> miriam: we're running into a case where people set containment explicitly, and where they set it implicitly (e.g. via container queries). for container queries the minimum containment required is desired. Maybe there is a way to address that with new modes or keywords.<br>
&lt;dholbert> correcting earlier notes, iank had actually said "Chromium is the only implementation to treat `break-inside:avoid` as monolithic"<br>
</details>


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


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

Received on Wednesday, 26 June 2024 17:02:00 UTC