csswg-drafts

csswg-drafts copied to clipboard

It would be good to clarify how text-wrap: balance interacts with line-clamp.

Specifically, when both balancing and clamping are requested, in which order do these effects operate? Does the block first have its lines wrapped using the balance algorithm, and then clamping applied to the resulting lines (without affecting how they wrap), or is clamping applied first and then balancing applied only to the lines up to the clamp limit?

Or in simpler terms, is it expected that (-webkit-)line-clamp may change the line-breaks used in a block?

It seems most intuitive to me that line-clamp applies after the line-breaks for a block have been determined, as it is defined in terms of lines. But the test at https://wpt.live/css/css-text/white-space/text-wrap-balance-line-clamp-001.html appears to assume that text-wrap: balance will be applied only to the lines up to the -webkit-line-clamp limit.

This codepen has an example where this effect is visible. In current Chrome Canary, varying the line-clamp limit results in changes to the line-breaking throughout the paragraph. Is this the expected/desired behavior, or should it be considered a bug?

Depending on the answer to this, the text-wrap-balance-line-clamp-001.html test may need revision.

It seems most intuitive to me that line-clamp applies after the line-breaks for a block have been determined

FWIW we (Blink) previously had this behaviour - but after web-developers tested this interaction they were confused believing that text-wrap: balance was broken for this case.

Based on this feedback we changed it to only balance the lines within the line-clamp range. We haven't received any bug reports since for this interaction.

cc/ @kojiishi

Thanks for the comment, Ian, that's interesting. I'm curious if people considered the implications of this for dynamically-varying line-clamp, or looked only at static examples?

In the purely static case, balancing only the displayed lines makes good sense, but I find the dynamic behavior where changing the line-clamp value causes line-wrapping to change to be a bit disconcerting. Interested to hear what other people think...?

I'm curious if people considered the implications of this for dynamically-varying line-clamp, or looked only at static examples?

From examples I've seen - most folks have a non-dynamic line-clamp (super rare to animate this). If it does change (say based on viewport/container width, etc) I suspect most web developers would still expect it to balance the visible lines.

(FWIW we received this feedback from more that one set of developers trying the API - e.g. wasn't a single voice).

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

The full IRC log of that discussion

<frances> Alan: what do we do with line-clamp in next issue?
<florian> q+
<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
<astearns> ack florian
<frances> Johnathan: Not clear of the difference
<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.
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/9310#issuecomment-1708989604
<astearns> ack fantasai
<frances> Florian: doing balancing first then adding the ellipsis probably makes the most sense, might not stay true with other variants
<andreubotella> q+
<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
<astearns> ack andreubotella
<florian> s/doing balancing first then adding the ellipsis/doing clamping first then adding the ellipsis then balancing
<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?
<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./
<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
<astearns> ack florian
<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
<astearns> ack fantasai
<frances> Alan: Any more opinions?
<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
<frances> Alan: Would we consider having different behavior on the static versus dynamic case?
<frances> Jonathan: Don't want to implement two ways of doing it
<frances> Alan: See point of shifting the different line breaks, not sure what to do with discrepancy
<frances> Florian: syntax wise we can choose between the two behavior, need to find a way to choose between both behaviors
<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
<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
<frances> Alan: Once in view, the line breaks should not change, expanding might shift the lines.
<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
<frances> Alan: Not resolved today. Will be on a later agenda to discuss more.

From examples I've seen - most folks have a non-dynamic line-clamp (super rare to animate this)

Animating based on an explicit number of line is likely to be very rare indeed.

However, once it becomes possible to clamp on a height, rather than on an explicit number of lines, that's likely a lot less rare: animating/transitioning the element itself to reveal the hidden lines, or having the element's height change because it's container's size changed… I don't think that'll be all that rare.

Removed the RESOLVED line from the summary posted by the bot, as it actually belonged to the previous issue on the agenda, https://github.com/w3c/csswg-drafts/issues/9112, and putting back on the Agenda, since that's what we said we'd do

I think an animation case is still one that is ok not to consider here. To reproduce it, an author must specify:

1. line-clamp
2. text-wrap: balance
3. Dynamically changing height.
4. Have a transition/animation for it (potentially requiring calc-size, as the common case is to expand fully to auto).

The issue from the current behavior (not pretty animation, which could be easily missed if it is ~200-300ms) is minor enough to grant a change this in other direction. As an author/designer, if I would encounter a case like this in my product, I'd either remove text-wrap: balance, or change the line-clamp to something different (like fading into a gradient), or just dismiss the issue.

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

The full IRC log of that discussion

<fantasai> florian_irc: do we clamp first and then balance, or balance first and then clamp?
<fantasai> florian_irc: dominant view in the issue is clamp first, then balance
<fantasai> florian_irc: but jfkthame points out that if you animate the height, this could be a lot of rebalancing
<fantasai> florian_irc: which is weird
<fantasai> jfkthame: the current safari tech preview seems to do balance and then clamp behavior
<fantasai> jfkthame: opposite of Blink
<dbaron> fantasai: if we want both behaviors, we could change based on 'will-change'
<dbaron> fantasai: could clamp-then-balance if it doesn't have 'will-change', and vice-versa
<fantasai> florian_irc: the fewer additional corner cases we add for fragmentation etc the better it is for later
<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
<fantasai> astearns: and in other case, animating is bad
<fantasai> florian_irc: animatable way seems complicated in general case. With simple version of line-clamp probably alright
<fantasai> florian_irc: assume part after laid out same as before
<fantasai> florian_irc: but if we have `continue: fragment`, the next fragment might be a different width
<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?
<kizu> q+
<fantasai> [balancing independently before/after line breaks or page breaks]
<astearns> ack fantasai
<astearns> ack kizu
<dbaron> fantasai: It's a little bit not what 'will-change' was designed for.
<dbaron> [in response to astearns asking why fantasai was laughing when suggesting the switch]
<fantasai> kizu: this seems like a rare enough use case... for authors if the animation is fast enough you won't notice
<fantasai> ... and can otherwise work around it
<fantasai> kizu: will-change suggestion is kinda weird, maybe better to use a dedicated switch
<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.
<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
<fantasai> astearns: given that jfkthame's test results consider this a change in WebKit, is that Ok with WebKit?
<dbaron> I agree with Florian that it's a rare case and we should pick something and not add switches.
<fantasai> fantasai: Seems reasonable to try, since it seems that would be desired by authors.
<fantasai> RESOLVED: Clamp, then balance