Re: [csswg-drafts] [css-text-4 / css-overflow-4] Interaction of `text-wrap: balance` and `(-webkit-)line-clamp` (#9310)

The CSS Working Group just discussed ``[css-text-4 / css-overflow-4] Interaction of `text-wrap: balance` and `(-webkit-)line-clamp` ``, and agreed to the following:

* `RESOLVED: Clamp, then balance`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> florian_irc: do we clamp first and then balance, or balance first and then clamp?<br>
&lt;fantasai> florian_irc: dominant view in the issue is clamp first, then balance<br>
&lt;fantasai> florian_irc: but jfkthame points out that if you animate the height, this could be a lot of rebalancing<br>
&lt;fantasai> florian_irc: which is weird<br>
&lt;fantasai> jfkthame: the current safari tech preview seems to do balance and then clamp behavior<br>
&lt;fantasai> jfkthame: opposite of Blink<br>
&lt;dbaron> fantasai: if we want both behaviors, we could change based on 'will-change'<br>
&lt;dbaron> fantasai: could clamp-then-balance if it doesn't have 'will-change', and vice-versa<br>
&lt;fantasai> florian_irc: the fewer additional corner cases we add for fragmentation etc the better it is for later<br>
&lt;fantasai> astearns: I'm convinced that people want both. In case where you're not animating, if you do it one way it looks like balance doesn't do anything<br>
&lt;fantasai> astearns: and in other case, animating is bad<br>
&lt;fantasai> florian_irc: animatable way seems complicated in general case. With simple version of line-clamp probably alright<br>
&lt;fantasai> florian_irc: assume part after laid out same as before<br>
&lt;fantasai> florian_irc: but if we have `continue: fragment`, the next fragment might be a different width<br>
&lt;fantasai> florian_irc: I'm not even sure if you move the clamping point between containers of different widhts before you clamp, what does that mean?<br>
&lt;kizu> q+<br>
&lt;fantasai> [balancing independently before/after line breaks or page breaks]<br>
&lt;astearns> ack fantasai<br>
&lt;astearns> ack kizu<br>
&lt;dbaron> fantasai: It's a little bit not what 'will-change' was designed for.<br>
&lt;dbaron> [in response to astearns asking why fantasai was laughing when suggesting the switch]<br>
&lt;fantasai> kizu: this seems like a rare enough use case... for authors if the animation is fast enough you won't notice<br>
&lt;fantasai> ... and can otherwise work around it<br>
&lt;fantasai> kizu: will-change suggestion is kinda weird, maybe better to use a dedicated switch<br>
&lt;fantasai> florian_irc: agree this is a rare case. not that revealing progressivly is not rare, but on something that has balance seems rare. For headlines etc.<br>
&lt;fantasai> florian_irc: so my inclination is to start by clamp then balance, and if we need an opt in later we worry how it works then<br>
&lt;fantasai> astearns: given that jfkthame's test results consider this a change in WebKit, is that Ok with WebKit?<br>
&lt;dbaron> I agree with Florian that it's a rare case and we should pick something and not add switches.<br>
&lt;fantasai> fantasai: Seems reasonable to try, since it seems that would be desired by authors.<br>
&lt;fantasai> RESOLVED: Clamp, then balance<br>
</details>


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


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

Received on Wednesday, 24 April 2024 15:41:13 UTC