[css-overflow-3] Define the behavior of overly long block ellipsis strings

[frivoal]

(Follow up from #2882)

If the block overflow ellipsis string is too long, the spec currently does not define what should happen.

Two behaviors have been proposed as probably reasonable. I think we should chose one, because interop is good, and

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Maecenas quis convallis nisl, sit amet molestie magna.

p {
  width: 5em;
  line-clamp: 4;
  block-ellipsis: "…to be continued…";
  border: 1px solid black;
}

---

First possibility: treat the ellipsis as an unbreakable string, as if white-space: nowrap
had been applied to it. Result:

---

Second possibility: allow the ellipsis to line break, according to the usual line breaking rules, and remove text in preceeding lines as necessary to make room for it. Result:

---

Note that this problem only ever occurs when we have a combination of short lines and a long ellipsis string. Authors can be careful and stay clear of this.

Personally, I think that the second possibility is generally preferable, but that it may not be worth the complexity, particularly when you take into account the interaction with #2905 (comment).

I would therefore suggest that we decide on the first possibility. And if we later want to introduce the idea of replacing content in earlier lines, we can add a switch. We may not even need a new property for that, and might be able to retroactively pretend that the UA stylesheet contains ::block-ellipsis { white-space: nowrap; } and allow authors to set it to white-space: normal if we can figure out how to make it work. But we don't have to worry about that for now.

However, if implementer are conformable with going with the second possibility, I'm certainly not opposed to it. I just want to avoid specifying something overly complex for an avoidable corner case, and risk have that get in the way of implementing the more useful parts of this feature.

[css-meeting-bot]

The CSS Working Group just discussed long block ellipsis strings, and agreed to the following:

• RESOLVED: ellipsis string is non breakable

The full IRC log of that discussion

<astearns> topic: long block ellipsis strings
<astearns> github: https://github.com//issues/3213
<eae> florian: I have a paragraph with lorem ipsum, the width is very narrow, we line clamp it and have ellipsis. What should happen when the ellipsis itself is longer than the line. One option is to consider the ellipsis unbreakable and have it stick out.
<eae> florian: The alternative, it is wrappable, and wraps up into the previous line.
<eae> myles__: How does the implemention know which line to start on?
<eae> florian: I feel it is an edge cases that will rarely happen, first option seems a lot easier.
<eae> TabAtkins: The wrapping behavior doesn't solve the problem of it being too wide
<eae> florian: Do we need to solve the porblem where it could wrap. I suggest we don't.
<eae> florian: Third way is leave it undefined, don't like it.
<eae> TabAtkins: Should be similar to have we do ellipsis now, remove enough characters until it fits
<eae> fantasai: This seems easier, don't have to care about the many ways of doing wrapping.
<eae> fantasai: I think the proposed resolution is to go with the first option
<eae> Proposed resolution: ellipsis is treated as unwrappable and will extend outside
<eae> TabAtkins: It's not great to overflow but at least you can see it.
<eae> astearns: Objections?
<eae> RESOLVED: ellipsis string is non breakable