[css-overflow] block-ellipsis rules don't match text-overflow rules

[andyearnshaw]

The spec text for text-overflow says:

For the ellipsis value implementations must hide characters and atomic inline-level elements at the end edge of the line as necessary to fit the ellipsis, and place the ellipsis immediately adjacent to the end edge of the remaining inline content. The first character or atomic inline-level element on a line must be clipped rather than ellipsed.

Whereas for block-ellipsis, the spec text says

This inline is assigned unicode-bidi: plaintext and line-height: 0 and 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.

As far as I understand, a soft-wrap opportunity usually means a hyphen, space or some other non-alphanumeric character depending on the language. The 'last soft wrap oppurtunity' could appear quite early on in the line of text. This matches the behaviour of -webkit-line-clamp.

We're using -webkit-line-clamp on our data tables, where the browser supports it. Our row heights are configurable, so there could be one or more lines of text. This has led to a current customer issue where email addresses with hyphens are clipped very early, leaving a lot of space in the cell:

Our plan to work around this is to use line-break: anywhere when we set -webkit-line-clamp: 1. However, this only solves the issue for single-lines of text. Wherever we have multiple lines, we'll hit the same issue:

Ideally, we want to wrap text suitably so that it is readable, but still show as much text as possible on the last line before the ellipsis is inserted, the same as text-overflow. This maximises the amount of information the user will see and may mean they don't need to resize the row or column. We also want to be able to use the same CSS, regardless of whether the number of lines of text is 1, 10 or 100, otherwise we need a JavaScript solution (like the one we have at the moment) that relies on forced reflows to do the calculations.

No browsers have implemented block-ellipsis yet, so I'm hoping that it's not too late to have this discussion. Is it something that has come up before?

[fantasai]

Seems like we would need to add a control to have block-ellipsis opt into either using normal line-breaking distinctions or the same as line-break: anywhere, either as a flag on block-ellipsis itself or as a separate property that applies to block-ellipsis and text-overflow (with the initial value being a value that does different things on each).

[frivoal]

This seems related to #7919

[frivoal]

Also related to #5417 and maybe #3937

[frivoal]

Another related issue: #4406

[andyearnshaw]

So it seems there are a few different threads about this, indicating some demand, but nobody is working on a design or proposal? Thinking about our own use case, where we want text to be readable but display as much content as possible on the last line, I imagine a few different straw options:

1. Extend line-break to allow an extra token for the last rendered line:

div {
  line-break: auto anywhere;
}

2. A new rule, e.g. line-break-last

div {
  line-break: auto;
  line-break-last: anywhere;
}

3. A new keyword for line-break

div {
  line-break: clamped-auto;
}

4. A new pseudo-element, e.g. ::last-line, ::clamped-line or something

div {
  line-break: auto;
}
div::last-line {
  line-break: anywhere;
}

That last option is likely the most complex as it would allow more rules to be affected and require much more thought about potential issues than I've given it. Probably rules it out. I'm not really sure if I have a particular preference, but hopefully those are some ideas that can help start a discussion towards an actual design/proposal.