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;astearns> topic: [css-contain-2] contain:size shouldn't fragment as monolithic<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/5648#issuecomment-1240067326<br>
&lt;dandclark> florian: Situation is size containment has requirements about fragmentation we need to satisfy for it to work.<br>
&lt;dandclark> ...: Reused frag. of monolithing elements because if fulfilled reqs but it does more. Solves problem but with unecessary side effects. Can we relax solution to solve prob without side effects?<br>
&lt;dandclark> florian: Size containment requires size of element doesn't change when content changes, and if element isfragmented, size of fragments don't change<br>
&lt;dandclark> ...: COuld have first without second if move fragmentation point<br>
&lt;dandclark> ...: By saying size-contained element is monolithic,  do get that property.<br>
&lt;dandclark> ...: Slice the element &lt;missed> and that solves the problem.<br>
&lt;dandclark> ...: If the element contains content, maybe interesting in some scenarios the boxes themselves to that but the content is allowed to fragment in fixed-size fragments.<br>
&lt;dandclark> ...: If have 3 lines of text in element and frag point is in middle of second line, take the entirety of second line and put it in next fragment<br>
&lt;dandclark> ...: 2nd and 3rd line could fit in second fragment without overflow<br>
&lt;dbaron> sounds a lot like printing on paper<br>
&lt;dandclark> ...: Could be interesting to allow browser to either slice or allow content, but allow fragmentation within these sizes.<br>
&lt;dandclark> ...: Should we do this? I don't think any browser does now.<br>
&lt;iank_> I slightly prefer leaving as is<br>
&lt;dandclark> ...: But could be interesting to allow them to<br>
&lt;dandclark> iank: The way that balancing works is that it does need to know about contents and where you slice<br>
&lt;dandclark> ...: and that has depenency on height. Also engines don't implement fragmentation primitives well. Hesitant about adding another<br>
&lt;miriam> q+<br>
&lt;dandclark> ...: especially for such a narrow use case<br>
&lt;dandclark> ...: So prefer leaving it<br>
&lt;astearns> ack miriam<br>
&lt;dandclark> miriam: As container queries beome more popular, how much of an edge case [cut off]<br>
&lt;dandclark> iank: This is only needed when got full size ontainment or containment in block axis<br>
&lt;dandclark> ...: Not needed in inline axis, which is dominant case for container queries<br>
&lt;dandclark> florian: I think that's true, havent thought about it a lot<br>
&lt;dandclark> florian: way I was proposing to address was to invent something to size the content the same; don't require but allow normal fragmentation<br>
&lt;dandclark> ...: It's just an allowance, don't have to take it<br>
&lt;dandclark> ...: Theoretically it would be fine. But only worth speccing if there's interest in pursuing it.<br>
&lt;dandclark> ...: Another solution is to defer it and look again in 5 years<br>
&lt;dandclark> ...: Not time sensitive since it's an allowance only anyway<br>
&lt;dandclark> iank: Don't have immediate interest. Prefer leaving as monolithic at the moment. Can change later if there's demand.<br>
&lt;dandclark> ...: There's demand for strongly making elements monolithic.<br>
&lt;dandclark> ...: Which capability doesn't exist now.<br>
&lt;dandclark> ...: There are cases where break inside avoid &lt;missed>. I can raise separate issue about that<br>
&lt;dandclark> florian: My sense is for this issue, defer it long term. Nothing wrong with proposed solution but no point if no one wants to do it.<br>
&lt;astearns> ack fantasai<br>
&lt;dandclark> ...: Can close issue, or mark deferred.<br>
&lt;dandclark> fantasai: If want to allow in future, should put it in spec, otherwise people won't know we considered it.<br>
&lt;dandclark> ...: If think it's bad idea, should close no change<br>
&lt;dandclark> iank: Not sure if good or bad idea. It's ehhh.<br>
&lt;tantek> do we already link to it in-context in the spec as an open issue? so implementers can be more aware of it?<br>
&lt;dandclark> fantasai: People make web page, use containment stuff. Then try to print the doc. Do we think it's best to cut lines in half?<br>
&lt;dandclark> ...: I expect contain to be used all over the place. So significant amount of printed content will be cut in half.<br>
&lt;dandclark> iank: Disagree w/ premise. Inline size containmnent will be used heavily, but full size containment not that prevalent.<br>
&lt;chris> Havent seen bisected lines of text on printing since, like, Netscape 2 or something<br>
&lt;dandclark> astearns: Out of time. Will leave issue and keep discussing.<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-1317434754 using your GitHub account


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

Received on Wednesday, 16 November 2022 18:02:20 UTC