[css-overflow] `text-wrap-style` interaction with height-based `line-clamp`

[andreubotella]

block-ellipsis is specified as affecting the line-breaking of a line, such that the width of the block overflow ellipsis is subtracted from the available width of the line. This means that, if a line must be ellipsized, its line height might be shorter than it would otherwise, since there might be tall content at the end of the line that would be pushed to the next line. (And with text-wrap: pretty or text-wrap: balance, it could be possible for the line height to also grow when ellipsized.)

When used together with the max-lines property, this doesn't pose a problem. But it does for height-based clamping, since the height of the lines determines in which line the ellipsis is placed, which in turn determines the height of the lines.

Note that currently, no browser implements block-ellipsis the way it's specified. The ellipsis behavior of -webkit-line-clamp in all browsers is to line-break without taking the ellipsis into account, and then apply the text-overflow: ellipsis behavior on the line to ellipsize, except the ellipsis is placed even if the line doesn't overflow. A line-clamp implementation that allows height-based clamping and uses this ellipsis behavior (like the one I'm working at in Chromium) would not have this circularity because the placement of the ellipsis on one line doesn't affect line-breaking.

@frivoal @bfgeek @kojiishi

[frivoal]

When used together with the max-lines property, this doesn't pose a problem. But it does for height-based clamping, since the height of the lines determines in which line the ellipsis is placed, which in turn determines the height of the lines.

I thought we had been clear in the spec about this, but re-reading, I guess not: the intent is that, regardless of clamping on max-lines or clamping on height, you pick where you break based on the content before inserting the ellipsis. Then you insert the ellipsis in the last line (displacing content as necessary), and you do not reevaluate which line that is or whether to add back more content after you've done that, even if the ellipsis' insertion causes the line height to change (in any case, it may only shrink, never grow). (pretty sure we discussed this before, but unfortunately I've not yet been able to locate where).

We could/should have a separate discussion (I plan to file an issue) about whether the spec's approach to inserting the ellipsis is justified (I think it is), but in any case, we can easily solve the potential circularity here.

cc: @fantasai

[andreubotella]

Couldn't the presence of text-wrap: pretty or text-wrap: balance cause the ellipsis insertion to grow a line, if the line before had taller content?

[frivoal]

I had assumed that ellipsis insertion happened last, after line breaks are decided, but I guess that's not specified one way or the other.

We do have this Note in the spec, which confirms that intent:

Setting the block overflow ellipsis's line-height to 0 makes sure that inserting it cannot cause the line’s height to grow, which could cause further relayouts and potentially cycles. This is almost equivalent to inserting the block overflow ellipsis as a paint-time operation, except that it still participates in alignment and justification. The downside is that unusually tall / deep glyphs in the block overflow ellipsis may overflow.

but I think it is true that unless we normatively define that ellipsis insertion happens after the line breaks have been defined, then this property isn't guaranteed to hold.

Do you think there's any value in defining it otherwise?

[frivoal]

@bfgeek, @andreubotella: I think the discussions we had at TPAC were converging towards the idea that:

1. First you do layout normally.
2. Then, regardless of whether it's based on a line count or a height, you pick your clamp point.
   (if the content is short enough that there's no clamp, stop here)
3. Then you insert your ellipsis in the last line.
4. then if text-wrap-style is balance, you re-run balancing on the lines before the clamp point, with the added constraint (if your original algo didn't have that) that it cannot change the number of lines nor grow the height.

Importantly, even if you're clamping based on a height, you do not then re-run the selection of the clamp point after step 3 nor 4 to account for the fact that displacing content to insert the ellipsis or the rebalancing might have made the height shrink.

Taking text-wrap-style into account at step 1 is important because:

• when text-wrap-style is pretty, if you end up showing more/less lines (due to resizing, animations, transitions…), you want the whole thing to be largely stable and not have the already viewable lines re-giggle when you uncover more. (this is also why you don't re-run wrapping on the visible lines at step 4 if text-wrap-style is pretty).
• there's a chance your line count or height is big enough that you don't end up actually clamping, and you don't want to need to run layout again to balance/prettify after all when you find that out.

As for step 4, this is because if you have text-wrap-style: balance, and the lines you keep aren't balanced, that doesn't satisfy author intent (and IIRC there are chrome bugs report to prove it). And not only is there a chance that maybe you can balance the visible lines a little bit better if you don't take into account the hidden ones, even more importantly, the ellipsis may be a very different length than the content it displaces, if if you don't re-balance after that, it may look really out of whack.

In terms of "the added constraint", we could relax it a bit saying that if you picked your clamp point based on a number of lines, then re-balancing cannot change the line count (but it could change the height), and if you picked it based on a height, then it cannot grow the height (but could change the number of lines)

[andreubotella]

1. First you do layout normally.
2. Then, regardless of whether it's based on a line count or a height, you pick your clamp point.
   (if the content is short enough that there's no clamp, stop here)
3. Then you insert your ellipsis in the last line.
4. then if text-wrap-style is balance, you re-run balancing on the lines before the clamp point, with the added constraint (if your original algo didn't have that) that it cannot change the number of lines nor grow the height.

I'm looking at this again, and I think that at least for text-wrap: balance this might lead to lines being too short before the clamp point.

Consider the test case at https://wpt.live/css/css-text/white-space/text-wrap-balance-005.html:

div {
  font-family: monospace;
  width: 8ch;
  line-clamp: 2;
  text-wrap-style: balance;
}

<div>1 2 3 4 5 6 7 8 9</div>

Currently all browsers render this as

+--------+
|1 2 3 4 |
|5 6 7 8…|
+--------+

which looks reasonably balanced. However, if we follow this algorithm, the balancing in step 1 would include the third line (which without balancing only contains "9"), resulting in:

+--------+
|1 2 3   |
|4 5 6…  |
+--------+

I'd say that for text-wrap: balance, clamping by a number of lines should first clamp and place the ellipsis, and then balance. The equivalent when clamping by a height could be trickier to implement, but I think it's still feasible. For text-wrap: pretty it might make sense to take into account the whole paragraph, including any content after clamp, but it should be noted that Chromium's implementation currently also ignores lines after clamp, just like for balance.

I'm also wondering whether we should leave the line breaking of lines after the clamp point completely UA-defined. After all, this text will always be hidden, and the line breaks can only be observed via JS, or indirectly through visible abspos.