Re: [csswg-drafts] [css-overflow] [css-text] Interaction between whitespace collapsing and line-clamp (#12008)

> This could also be related (or not): even without disabling whitespace collapsing, occasionally, although less often, the ellipsis are still rendering after a space. Any idea if this is expected, related to the spec, or browser implementation quirk? I reproduces it in Blink, Gecko and Webkit:

The current behavior of `-webkit-line-clamp` in all browsers is that, if adding the ellipsis to the line will make it overflow, characters (well, glyphs) are removed one by one from the end of the line until it fits, and then the ellipsis is placed. This means the last character that was not clamped might very well be a space.

This behavior was never in the spec, but Webkit's original non-standard implementation followed `text-overflow: ellipsis`'s behavior, and all browsers copied that before there was even a spec for `-webkit-line-clamp`.

Once the spec was written, though, we aimed for a different behavior: rather than removing characters, we'll place the ellipsis at the last linebreak opportunity where the ellipsis will still fit. If the ellipsis still fits in the remainder of the line, it will be placed there; otherwise, it will remove the last word (or if hyphenation is enabled, the last chunk of a long word). And since per Unicode linebreak opportunities come _before_ whitespace, not after it, this brings up the question of whether final spaces should also be removed. This is the behavior that `line-clamp` will have when it ships, and hopefully we can also change `-webkit-line-clamp` to have that as well.

-- 
GitHub Notification of comment by andreubotella
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12008#issuecomment-3221015782 using your GitHub account


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

Received on Monday, 25 August 2025 16:55:25 UTC