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

frivoal has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-overflow-3] Define the behavior of overly long block ellipsis strings ==
(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 

```markup
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Maecenas quis convallis nisl, sit amet molestie magna.
```
```css
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:
![screenshot 2018-10-16 12 46 53](https://user-images.githubusercontent.com/113268/46991626-b4ba7c80-d141-11e8-9957-ce500491f488.png)

----
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:
![screenshot 2018-10-16 12 49 40](https://user-images.githubusercontent.com/113268/46991699-f64b2780-d141-11e8-9169-3f9a2e64daf1.png)

----

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 https://github.com/w3c/csswg-drafts/issues/2905#issuecomment-404108254.

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.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3213 using your GitHub account

Received on Tuesday, 16 October 2018 04:00:07 UTC