[css-overflow] interaction between text-overflow:ellipsis and line-clamp #10823

frivoal · 2024-09-03T01:26:04Z

http://wpt.live/css/css-overflow/line-clamp/webkit-line-clamp-036.html and http://wpt.live/css/css-overflow/line-clamp/webkit-line-clamp-037.html assume that if -webkit-line-clamp is on, the text-overflow: ellipsis has no effect.

This is not backed up by the spec, which expects both effects to be independent. Assuming the preconditions for both properties are fulfilled:

if there are more lines than the clamp number, the excess lines are clamped, and an ellipsis is shown on the last line
if some (non clamped) lines are too long and overflow, they get truncated and an ellipsis is added at their end.

The spec also defines how the two interact when they'd happen on the same line, which can happen given that the string for line-clamp can be customized to something different, and possibly longer, than "…":

The UA must treat the block overflow ellipsis as an unbreakable string, If any part of the block overflow ellipsis overflows, it is treated as scrollable overflow, and its rendering is affected by the text-overflow property.

Should we:

consider the tests to be wrong, fix it, and keep the spec as is?
rationale: if gives maximum control to authors, and the interaction can be useful
change the spec to turn off text-overflow: ellipsis when using -webkit-line-clamp for compat reasons, but not when using line-clamp?
rationale: this behavior originated in a compat workaround, but keep authors in control in the unprefixed version which does not have compat bagage
change the spec to turn off text-overflow: ellipsis when using either -webkit-line-clamp or line-clamp?
rationale: this behavior originated in a compat workaround, and keep both prefixed and unprefixed versions consistent

cc: @andreubotella @bfgeek

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

andreubotella · 2024-09-03T08:19:05Z

It seems like Chromium and Gecko turn off text-overflow: ellipsis inside -webkit-line-clamp, but Webkit doesn't. Interestingly, as webkit-line-clamp-037 shows, if the -webkit-line-clamp line number is the last line, then it doesn't ellipsize, regardless of text-overflow: ellipsis. I suspect this is a bug.

As far as I can tell, the ellipsis behavior of -webkit-line-clamp in all browsers is "line break, then on the line to ellipsize, behave like text-overflow: ellipsis except that the ellipsis should be added even if the line doesn't overflow". No browser currently has the block-overflow behavior where the ellipsis is taken into account when line breaking. If this behavior stays the same (which is a different issue), then depending on the implementation, it might be hard to make block-ellipsis and text-overflow interact on the same line.

frivoal · 2024-09-09T06:21:32Z

No browser currently has the block-overflow behavior where the ellipsis is taken into account when line breaking.

Depending on exactly what you mean by this, I don't think this is actually what the spec calls for. My understanding is:

line break (without taking the ellipsis into account)
count lines or measure the height, an clamp based on that if there are too many lines if it it's too high.
if we did clamp, remove some content on the last line to make room for the ellipsis, and then insert it (don't re-wrap after doing that)
text-align

Now, at step 3, the spec does call for taking line-breaking opportunities into account in order to find what chunks of content you can actually remove:

[the block ellipsis] is placed in the line box after the last soft wrap opportunity (see [CSS-TEXT-3]) that would still allow the entire block overflow ellipsis to fit on the line.

In this approach, it's not "taken into account when line breaking". Line breaking is step 1, and the ellipsis is ignored then. Yes, step 3 uses some concepts related to line breaking (soft wrap opportunities), but I don't think this should have an impact.

With this clarification, do you still think it is hard to make block-ellipsis and text-overflow interact on the same line?

andreubotella · 2024-09-10T00:22:01Z

if we did clamp, remove some content on the last line to make room for the ellipsis, and then insert it (don't re-wrap after doing that)

With continue: collapse, would that content be inserted on the next line? The next line is hidden, but the position of its content can be detected from JS. And if so, that means that the displaced content can't just be hidden from paint and replaced with an ellipsis the way it currently is in browsers, since I think otherwise you'd end up with duplicated words in the accessibility tree.

I think the interaction with text-wrap-style needs to be looked at more. text-wrap: balance must only apply to the lines before clamp (and as far as I can tell, Chromium's implementation of text-wrap: pretty does the same). But if the lines can have content with different heights, then which lines are before clamp cannot be determined independently from balancing/prettifying.

If the line breaks are chosen as with text-wrap-style: auto, and then a particular line number is chosen as the clamp point before doing a balanced/prettified relayout, then it's possible for this relayout to have a greater height. I think the same holds if the initial layout balances/prettifies the whole paragraph.

frivoal · 2024-09-10T01:14:12Z

With continue: collapse, would that content be inserted on the next line? The next line is hidden, but the position of its content can be detected from JS. And if so, that means that the displaced content can't just be hidden from paint and replaced with an ellipsis the way it currently is in browsers, since I think otherwise you'd end up with duplicated words in the accessibility tree.

Up to you, since you're the one proposing/defining it :)

But yes, I would expect that unlike continue :discard, continue: collapse would not try to push that content forward to the next line, and would simply hide it.

frivoal · 2024-09-10T01:20:23Z

I think the interaction with text-wrap-style needs to be looked at more.

Possibly, yes. I wonder if we should handle that as a two-passes thing: first, do greedy line breaking, find the clamp point based on that, then rewrap lines using the pretty or balance approach, then if that increase the height or the number of lines beyond the clamp point, clamp again (but don't re-wrap after that), then insert the ellispsis (and don't rewrap after that).

frivoal · 2024-11-04T08:49:23Z

I think the interaction with text-wrap-style needs to be looked at more.

See #10827 (comment)

css-meeting-bot · 2025-04-02T14:13:09Z

The CSS Working Group just discussed [css-overflow] interaction between text-overflow:ellipsis and line-clamp, and agreed to the following:

RESOLVED: Close no change (text-overflow shoudl work as normal in line-calmp containers)

The full IRC log of that discussion

andreubotella: in chrome's impl of -webkit-line-clamp if you set text-overflow:ellipsis
andreubotella: that will not take effect
andreubotella: i'm not sure if webkit's behavior, originally or currently, works liek that
(there's no ellipsis)
q+
andreubotella: the ellipsis defined by block-ellipsis is a different thing than text-overflow:ellipsis
andreubotella: block-ellipsis is specified to be placed at a soft-wrap opportunity
andreubotella: so with current spec text, text-overflow and block-overflow can apply to same element
andreubotella: so in chromium we're going to ship line-clamp without letting you specify a custom block ellipsis
andreubotella: this'll only really have an effect on the lines before the clamp point
andreubotella: if you have a block-ellipsis set to a string, and it's a long string, longer than the line lenth, that interaction with clamping must be considered
andreubotella: the chromium impl currently has an impl of this, with block-ellipsis and breaking at soft wrap, behidn a flag
andreubotella: and that would not prevent text-overflow from also working on the same line
ack florian
florian: as a reminder, text-overflow:ellipsis, tho it also adds a ..., works super differently
florian: doesn't work on a block as a whole, it's on individual lines
florian: if a given line, after wrapping, overflows, it truncate sand visually places a ...
florian: no effect on layout
florian: lines after the last one (after clamp/balance/ellipse) and some lines above the clamp point overflow
florian: spec says to do the ellipsis on those
florian: i think theoreticaldly that's the right thing, but i think we don't really have a ton of use-cases for this
florian: i think text-overflow is best used on single-line things
florian: the things you use text-overflow:ellipsis on and line-calmp on are typically not the same
florian: so even tho they're specified to both work independently, if we said they can't work together, don't think i'd be sad
florian: second, for block-ellipsis with a long string, that might be long and overflow, then what
florian: spec currently says if the block-ellipsis overflow doesn't fit th eline, how you deal with *taht* is handled by text-overflow
florian: it gives you options for how to deal with the long ellipsis. makes sense in theory
q+
scribe+
ack TabAtkins
TabAtkins: I don't understand what interaction is happening that makes line-clamp not work with text-overflow:ellipsis
florian: It could happen in theory, just not happening in practice
TabAtkins: what happens when you do have an extra-long line in a line-clamped container?
andreubotella: In current implementation, if this is not the last line, nothing happens and line overflows.
andreubotella: If it's the last line, currently all implementations currently behave the same as text-overflow:ellipsis, but not in my prototype
TabAtkins: That's odd and unfortunate.
TabAtkins: I really don't see why they're linked. Maybe some reason in implementation, but seems very strange.
TabAtkins: The one case that they should both work together is

 is to have text-overflow to not be too long, and line-clamp to not be too long

 q+

 TabAtkins: having to choose between overflow down vs overflow to the side seems bad. IDK why we are adopting such a limitation

 andreubotella: I don't know why that is the case. It was the case when I started working on line-clamp

 andreubotella: I expect it's because initially the ellipsis for line-clamp was implemented the same way as text-ellipsis

 andreubotella: I don't know why it wouldn't apply to other lines

 ack fantasai

 fantasai: i think i agree with TAb that it doesn't amke sense for these to be interacting. text-overflow just applies after you do all the line-clamp stuff, makes sense

 fantasai: it seems reasonble that if the -webkit-overflow did their ellipsis with the text-overflow mechanism, it doesn't work. makes sense as an accciendtal limitation

 ack florian

 florian: the early ipml was quick and dirty, it used and abused all sorts of parts. that's almost certainly why you can't do both at the same time.

 florian: my hope is to keep the spec as it is, hope browsers fix it.

 florian: Hopefuly the interaction is rare enough that even if browsers dont' get it right currently that's okay

 astearns: and the spec currently says you do both?

 florian:

 astearns: is there an ordering?

 florian: yeah they're independent. after everything else, if some individual lines overflow, you text-overflow ellipsize them

 andreubotella: yeah, spec says after everything is done, if a line overflows it's handled by text-overflow

 astearns: so closing this issue no change?

 florian: i think so. is that okay, Andreu?

 andreubotella: yeah, i don't have a problem with that

 astearns: objections?

 RESOLVED: Close no change (text-overflow shoudl work as normal in line-calmp containers)

Since `-webkit-line-clamp` was first implemented in Webkit, using line clamping would prevent `text-overflow: ellipsis` from working inside the line clamp container. This seems to have been a side effect of the initial implementation, and it was kept as it was when the implementation was redone for LayoutNG, even though that is no longer a side effect. Recently, in w3c/csswg-drafts#10823 the CSSWG resolved that `text-overflow: ellipsis` should apply inside a line-clamp container. For the last line until clamp, if `text-overflow: ellipsis` also applies to it, the line clamp ellipsis is applied first -- however, since we currently only support ellipsis, rather than a text string, for both the `text-overflow` and line-clamp ellipses, this would be identical to only applying the line clamp ellipsis. This change also removes the `LineClampData::State::kDontTruncate` state, which was set when there was no possibility of clamping, but `text-overflow: ellipsis` should still not apply because we were still inside the line-clamp container. Since `text-overflow: ellipsis` now should apply in those cases, we remove that state, and use `kDisabled` instead. We also add an `ignore_line_clamp` flag to `BlockLineClampData` to know to ignore the line-clamp properties when performing a relayout without clamping. Additionally, this change updates some WPT tests that were rendered incorrect with this resolution. Bug: 40336192, 407971271 Change-Id: I06e43011a12ba27507b6f661c7b0484d6587cf19

Since `-webkit-line-clamp` was first implemented in Webkit, using line clamping would prevent `text-overflow: ellipsis` from working inside the line clamp container. This seems to have been a side effect of the initial implementation, and it was kept as it was when the implementation was redone for LayoutNG, even though that is no longer a side effect. Recently, in w3c/csswg-drafts#10823 the CSSWG resolved that `text-overflow: ellipsis` should apply inside a line-clamp container. For the last line until clamp, if `text-overflow: ellipsis` also applies to it, the line clamp ellipsis is applied first -- however, since we currently only support ellipsis, rather than a text string, for both the `text-overflow` and line-clamp ellipses, this would be identical to only applying the line clamp ellipsis. This change also removes the `LineClampData::State::kDontTruncate` state, which was set when there was no possibility of clamping, but `text-overflow: ellipsis` should still not apply because we were still inside the line-clamp container. Since `text-overflow: ellipsis` now should apply in those cases, we remove that state, and use `kDisabled` instead. We also add an `ignore_line_clamp` flag to `BlockLineClampData` to know to ignore the line-clamp properties when performing a relayout without clamping. Additionally, this change updates some WPT tests that were rendered incorrect with this resolution. Bug: 40336192, 407971271 Change-Id: I06e43011a12ba27507b6f661c7b0484d6587cf19 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6470150 Reviewed-by: Ian Kilpatrick Reviewed-by: Koji Ishii Commit-Queue: Andreu Botella Cr-Commit-Position: refs/heads/main@{#1451710}

andreubotella · 2025-04-25T12:19:13Z

No spec changes are needed, and tests for this resolution have been merged in web-platform-tests/wpt#52120.

Since `-webkit-line-clamp` was first implemented in Webkit, using line clamping would prevent `text-overflow: ellipsis` from working inside the line clamp container. This seems to have been a side effect of the initial implementation, and it was kept as it was when the implementation was redone for LayoutNG, even though that is no longer a side effect. Recently, in w3c/csswg-drafts#10823 the CSSWG resolved that `text-overflow: ellipsis` should apply inside a line-clamp container. For the last line until clamp, if `text-overflow: ellipsis` also applies to it, the line clamp ellipsis is applied first -- however, since we currently only support ellipsis, rather than a text string, for both the `text-overflow` and line-clamp ellipses, this would be identical to only applying the line clamp ellipsis. This change also removes the `LineClampData::State::kDontTruncate` state, which was set when there was no possibility of clamping, but `text-overflow: ellipsis` should still not apply because we were still inside the line-clamp container. Since `text-overflow: ellipsis` now should apply in those cases, we remove that state, and use `kDisabled` instead. We also add an `ignore_line_clamp` flag to `BlockLineClampData` to know to ignore the line-clamp properties when performing a relayout without clamping. Additionally, this change updates some WPT tests that were rendered incorrect with this resolution. Bug: 40336192, 407971271 Change-Id: I06e43011a12ba27507b6f661c7b0484d6587cf19 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6470150 Reviewed-by: Ian Kilpatrick Reviewed-by: Koji Ishii Commit-Queue: Andreu Botella Cr-Commit-Position: refs/heads/main@{#1451710}

…is` work inside `line-clamp`, a=testonly Automatic update from web-platform-tests [line-clamp] Make `text-overflow: ellipsis` work inside `line-clamp` Since `-webkit-line-clamp` was first implemented in Webkit, using line clamping would prevent `text-overflow: ellipsis` from working inside the line clamp container. This seems to have been a side effect of the initial implementation, and it was kept as it was when the implementation was redone for LayoutNG, even though that is no longer a side effect. Recently, in w3c/csswg-drafts#10823 the CSSWG resolved that `text-overflow: ellipsis` should apply inside a line-clamp container. For the last line until clamp, if `text-overflow: ellipsis` also applies to it, the line clamp ellipsis is applied first -- however, since we currently only support ellipsis, rather than a text string, for both the `text-overflow` and line-clamp ellipses, this would be identical to only applying the line clamp ellipsis. This change also removes the `LineClampData::State::kDontTruncate` state, which was set when there was no possibility of clamping, but `text-overflow: ellipsis` should still not apply because we were still inside the line-clamp container. Since `text-overflow: ellipsis` now should apply in those cases, we remove that state, and use `kDisabled` instead. We also add an `ignore_line_clamp` flag to `BlockLineClampData` to know to ignore the line-clamp properties when performing a relayout without clamping. Additionally, this change updates some WPT tests that were rendered incorrect with this resolution. Bug: 40336192, 407971271 Change-Id: I06e43011a12ba27507b6f661c7b0484d6587cf19 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6470150 Reviewed-by: Ian Kilpatrick Reviewed-by: Koji Ishii Commit-Queue: Andreu Botella Cr-Commit-Position: refs/heads/main@{#1451710} -- wpt-commits: f70ccb743183524cdb23aa4fc3ce0343d1734fd2 wpt-pr: 52120

…is` work inside `line-clamp`, a=testonly Automatic update from web-platform-tests [line-clamp] Make `text-overflow: ellipsis` work inside `line-clamp` Since `-webkit-line-clamp` was first implemented in Webkit, using line clamping would prevent `text-overflow: ellipsis` from working inside the line clamp container. This seems to have been a side effect of the initial implementation, and it was kept as it was when the implementation was redone for LayoutNG, even though that is no longer a side effect. Recently, in w3c/csswg-drafts#10823 the CSSWG resolved that `text-overflow: ellipsis` should apply inside a line-clamp container. For the last line until clamp, if `text-overflow: ellipsis` also applies to it, the line clamp ellipsis is applied first -- however, since we currently only support ellipsis, rather than a text string, for both the `text-overflow` and line-clamp ellipses, this would be identical to only applying the line clamp ellipsis. This change also removes the `LineClampData::State::kDontTruncate` state, which was set when there was no possibility of clamping, but `text-overflow: ellipsis` should still not apply because we were still inside the line-clamp container. Since `text-overflow: ellipsis` now should apply in those cases, we remove that state, and use `kDisabled` instead. We also add an `ignore_line_clamp` flag to `BlockLineClampData` to know to ignore the line-clamp properties when performing a relayout without clamping. Additionally, this change updates some WPT tests that were rendered incorrect with this resolution. Bug: 40336192, 407971271 Change-Id: I06e43011a12ba27507b6f661c7b0484d6587cf19 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6470150 Reviewed-by: Ian Kilpatrick Reviewed-by: Koji Ishii Commit-Queue: Andreu Botella Cr-Commit-Position: refs/heads/main{#1451710} -- wpt-commits: f70ccb743183524cdb23aa4fc3ce0343d1734fd2 wpt-pr: 52120 UltraBlame original commit: ab51b6e73ebf58b95274f97b4825bede549a8081

…is` work inside `line-clamp`, a=testonly Automatic update from web-platform-tests [line-clamp] Make `text-overflow: ellipsis` work inside `line-clamp` Since `-webkit-line-clamp` was first implemented in Webkit, using line clamping would prevent `text-overflow: ellipsis` from working inside the line clamp container. This seems to have been a side effect of the initial implementation, and it was kept as it was when the implementation was redone for LayoutNG, even though that is no longer a side effect. Recently, in w3c/csswg-drafts#10823 the CSSWG resolved that `text-overflow: ellipsis` should apply inside a line-clamp container. For the last line until clamp, if `text-overflow: ellipsis` also applies to it, the line clamp ellipsis is applied first -- however, since we currently only support ellipsis, rather than a text string, for both the `text-overflow` and line-clamp ellipses, this would be identical to only applying the line clamp ellipsis. This change also removes the `LineClampData::State::kDontTruncate` state, which was set when there was no possibility of clamping, but `text-overflow: ellipsis` should still not apply because we were still inside the line-clamp container. Since `text-overflow: ellipsis` now should apply in those cases, we remove that state, and use `kDisabled` instead. We also add an `ignore_line_clamp` flag to `BlockLineClampData` to know to ignore the line-clamp properties when performing a relayout without clamping. Additionally, this change updates some WPT tests that were rendered incorrect with this resolution. Bug: 40336192, 407971271 Change-Id: I06e43011a12ba27507b6f661c7b0484d6587cf19 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6470150 Reviewed-by: Ian Kilpatrick Reviewed-by: Koji Ishii Commit-Queue: Andreu Botella Cr-Commit-Position: refs/heads/main@{#1451710} -- wpt-commits: f70ccb743183524cdb23aa4fc3ce0343d1734fd2 wpt-pr: 52120

frivoal added the css-overflow-4 label Sep 3, 2024

frivoal added the Agenda+ label Jan 30, 2025

astearns moved this to Regular agenda in CSSWG April 2025 meeting agenda Mar 27, 2025

astearns added this to CSSWG April 2025 meeting agenda Mar 27, 2025

astearns moved this from Regular agenda to Wednesday Morning in CSSWG April 2025 meeting agenda Mar 28, 2025

kizu assigned 5t3ph and unassigned 5t3ph Apr 2, 2025

css-meeting-bot removed the Agenda+ label Apr 2, 2025

chromium-helper mentioned this issue Apr 2, 2025

[css-overflow] interaction between text-overflow:ellipsis and line-clamp chromium-helper/csswg-resolutions#759

Closed

mozilla-apprentice mentioned this issue Apr 2, 2025

[css-overflow] interaction between text-overflow:ellipsis and line-clamp mozilla/wg-decisions#1874

Open

chromium-wpt-export-bot mentioned this issue Apr 23, 2025

[line-clamp] Make text-overflow: ellipsis work inside line-clamp web-platform-tests/wpt#52120

Merged

frivoal added Closed Rejected as Wontfix by CSSWG Resolution Needs Testcase (WPT) labels Jun 6, 2025

frivoal closed this as completed Jun 6, 2025

frivoal added Tested Memory aid - issue has WPT tests and removed Needs Testcase (WPT) labels Jun 6, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[css-overflow] interaction between text-overflow:ellipsis and line-clamp #10823

[css-overflow] interaction between text-overflow:ellipsis and line-clamp #10823

frivoal commented Sep 3, 2024 •

edited

Loading

andreubotella commented Sep 3, 2024 •

edited

Loading

Uh oh!

frivoal commented Sep 9, 2024

Uh oh!

andreubotella commented Sep 10, 2024 •

edited

Loading

Uh oh!

frivoal commented Sep 10, 2024

Uh oh!

frivoal commented Sep 10, 2024

Uh oh!

frivoal commented Nov 4, 2024

Uh oh!

css-meeting-bot commented Apr 2, 2025

Uh oh!

andreubotella commented Apr 25, 2025

Uh oh!

[css-overflow] interaction between text-overflow:ellipsis and line-clamp #10823

[css-overflow] interaction between text-overflow:ellipsis and line-clamp #10823

Comments

frivoal commented Sep 3, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

andreubotella commented Sep 3, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

frivoal commented Sep 9, 2024

Uh oh!

andreubotella commented Sep 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

frivoal commented Sep 10, 2024

Uh oh!

frivoal commented Sep 10, 2024

Uh oh!

frivoal commented Nov 4, 2024

Uh oh!

css-meeting-bot commented Apr 2, 2025

Uh oh!

andreubotella commented Apr 25, 2025

Uh oh!

frivoal commented Sep 3, 2024 •

edited

Loading

andreubotella commented Sep 3, 2024 •

edited

Loading

andreubotella commented Sep 10, 2024 •

edited

Loading