[css-overflow] `block-ellipsis` 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?