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: Forced break resets the balancing algorithm for text-wrap:balance`

<details><summary>The full IRC log of that discussion</summary>
&lt;frances> RESOLVED: Forced break resets the balancing algorithm for text-wrap:balance<br>
&lt;frances> Alan: what do we do with line-clamp in next issue?<br>
&lt;florian> q+<br>
&lt;frances> Johnathan: If line-clamp is in effect with only some blocks being displayed, should balance apply to the entire block and entire block being displayed? Approaches can give two different results<br>
&lt;astearns> ack florian<br>
&lt;frances> Johnathan: Not clear of the difference<br>
&lt;frances> Florian: complicated, line-clamp adds ellipses at the end of the line when being displayed, add before or after balancing? Generalization about whether same answer applies to text-wrap: pretty or not? Take into account all of the lines? One that uses fragmentation and one that doesn't.<br>
&lt;fantasai> -> https://github.com/w3c/csswg-drafts/issues/9310#issuecomment-1708989604<br>
&lt;astearns> ack fantasai<br>
&lt;frances> Florian: doing balancing first then adding the ellipsis probably makes the most sense, might not stay true with other variants<br>
&lt;andreubotella> q+<br>
&lt;frances> fantasai: Ian posted the issue that applied line clamp after breaking the line, developers weren't happy and changed the balancing, no negative feedback since<br>
&lt;astearns> ack andreubotella<br>
&lt;florian> s/doing balancing first then adding the ellipsis/doing clamping first then adding the ellipsis then balancing<br>
&lt;frances> Andreu: One issue would be for animating height to continue the clamp, not something that is being currently done, this is a use case that is not currently possible, I don't see it being very widely used. Might not become easily possible. Does that change things? Do we want that to continuously change the line breaks when the number of lines changes?<br>
&lt;andreubotella> s/I don't see it being very widely used/I don't see it being very widely used, but it might see some usage./<br>
&lt;frances> Florian: In case of balance not in case of pretty, two face definition of how balance, would be strange to balance, maybe ...elipsis is not bad, might have arbitrary strings, if balancing not taking it into account, need to know where to insert<br>
&lt;astearns> ack florian<br>
&lt;frances> Ian: Should be balancing less visible, if balancing the entire paragraph, lines might be less visible, less sure about balancing with elipsis or not. Sometimes goes in with the content, sometimes a hanging thing where not considered part of the block<br>
&lt;astearns> ack fantasai<br>
&lt;frances> Alan: Any more opinions?<br>
&lt;frances> Jonathan: Still conflicted, what Ian is proposing in issue. Looks well for the static case, if we find height of the element and vary line clamp as line height varies, line height might be disconcerting<br>
&lt;frances> Alan: Would we consider having different behavior on the static versus dynamic case?<br>
&lt;frances> Jonathan: Don't want to implement two ways of doing it<br>
&lt;frances> Alan: See point of shifting the different line breaks, not sure what to do with discrepancy<br>
&lt;frances> Florian: syntax wise we can choose between the two behavior, need to find a way to choose between both behaviors<br>
&lt;florian> s/syntax wise we can choose between the two behavior/syntax wise we could choose between the two behavior through "balance stable" as we already have that second keyword<br>
&lt;frances> Jonathan: I'd like to consider it a bit further particularly with the use case in mind of a block with one line and option to display more with the text staying stable<br>
&lt;frances> Alan: Once in view, the line breaks should not change, expanding might shift the lines.<br>
&lt;florian> s/need to find a way to choose between both behaviors/but that's only if we're actually interested in having both, which we might not be<br>
&lt;frances> Alan: Not resolved today. Will be on a later agenda to discuss more.<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-1885186015 using your GitHub account


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

Received on Wednesday, 10 January 2024 16:28:05 UTC