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

jfkthame · 2023-09-05T12:13:22Z

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.

The text was updated successfully, but these errors were encountered:

bfgeek · 2023-09-06T19:43:43Z

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

jfkthame · 2023-09-08T15:03:37Z

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...?

bfgeek · 2023-09-08T17:05:34Z

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).

…=emilio A simple form of balance for short blocks, implemented by incrementally reducing the effective inline-size used during line-breaking, up to the point where an extra line would be created. This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me if that test is correct (see w3c/csswg-drafts#9310). If we do want the behavior expected by that test, an additional patch to handle the interaction with line-clamp will be required. Depends on D187543 Differential Revision: https://phabricator.services.mozilla.com/D187544

…nsider only the lines up to the clamp limit. r=emilio This corresponds to how Chrome behaves, and passes the test they included in WPT. It's unclear to me whether this behavior actually follows from the current spec (see w3c/csswg-drafts#9310), but it seems to be the desired result. (I've put it behind a (default-enabled) pref for now, so that it's possible to experiment with the two possible interpretations, but we can remove the pref once the spec question is clarified/confirmed.) This patch also disables balancing for fragmented/overflowing blocks, as that will not currently work well. We may want to address that as a followup issue (though it won't matter to the primary balance use-cases such as titles). Depends on D188139 Differential Revision: https://phabricator.services.mozilla.com/D188220

…=emilio A simple form of balance for short blocks, implemented by incrementally reducing the effective inline-size used during line-breaking, up to the point where an extra line would be created. This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me if that test is correct (see w3c/csswg-drafts#9310). If we do want the behavior expected by that test, an additional patch to handle the interaction with line-clamp will be required. Depends on D187543 Differential Revision: https://phabricator.services.mozilla.com/D187544

…nsider only the lines up to the clamp limit. r=emilio This corresponds to how Chrome behaves, and passes the test they included in WPT. It's unclear to me whether this behavior actually follows from the current spec (see w3c/csswg-drafts#9310), but it seems to be the desired result. (I've put it behind a (default-enabled) pref for now, so that it's possible to experiment with the two possible interpretations, but we can remove the pref once the spec question is clarified/confirmed.) This patch also disables balancing for fragmented/overflowing blocks, as that will not currently work well. We may want to address that as a followup issue (though it won't matter to the primary balance use-cases such as titles). Depends on D188139 Differential Revision: https://phabricator.services.mozilla.com/D188220

…=emilio A simple form of balance for short blocks, implemented by incrementally reducing the effective inline-size used during line-breaking, up to the point where an extra line would be created. This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me if that test is correct (see w3c/csswg-drafts#9310). If we do want the behavior expected by that test, an additional patch to handle the interaction with line-clamp will be required. Depends on D187543 Differential Revision: https://phabricator.services.mozilla.com/D187544 UltraBlame original commit: 0fd4431f527935234d764a167cc5a20acfc323eb

…nsider only the lines up to the clamp limit. r=emilio This corresponds to how Chrome behaves, and passes the test they included in WPT. It's unclear to me whether this behavior actually follows from the current spec (see w3c/csswg-drafts#9310), but it seems to be the desired result. (I've put it behind a (default-enabled) pref for now, so that it's possible to experiment with the two possible interpretations, but we can remove the pref once the spec question is clarified/confirmed.) This patch also disables balancing for fragmented/overflowing blocks, as that will not currently work well. We may want to address that as a followup issue (though it won't matter to the primary balance use-cases such as titles). Depends on D188139 Differential Revision: https://phabricator.services.mozilla.com/D188220 UltraBlame original commit: 7ce2b41bb730247e00da9c69a1df9a01df80633d

…=emilio A simple form of balance for short blocks, implemented by incrementally reducing the effective inline-size used during line-breaking, up to the point where an extra line would be created. This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me if that test is correct (see w3c/csswg-drafts#9310). If we do want the behavior expected by that test, an additional patch to handle the interaction with line-clamp will be required. Depends on D187543 Differential Revision: https://phabricator.services.mozilla.com/D187544 UltraBlame original commit: eb0b125d3214a04c293cbe2f21184e85ae00302a

…nsider only the lines up to the clamp limit. r=emilio This corresponds to how Chrome behaves, and passes the test they included in WPT. It's unclear to me whether this behavior actually follows from the current spec (see w3c/csswg-drafts#9310), but it seems to be the desired result. (I've put it behind a (default-enabled) pref for now, so that it's possible to experiment with the two possible interpretations, but we can remove the pref once the spec question is clarified/confirmed.) This patch also disables balancing for fragmented/overflowing blocks, as that will not currently work well. We may want to address that as a followup issue (though it won't matter to the primary balance use-cases such as titles). Depends on D188139 Differential Revision: https://phabricator.services.mozilla.com/D188220 UltraBlame original commit: 16a3de29e4e69175f5a7c914ffa9de63b8683f2a