[css-overflow] ensure interactions between block-overflow and text-overflow are defined

[heycam]

https://drafts.csswg.org/css-overflow-3/#block-ellipsis

I wonder if there are any undefined interactions between text-overflow and block-overflow. For example is it clear what happens when you have:

<div style="line-clamp: 1; text-overflow: ellipsis; width: 2ch">
  supercalifragilisticexpialidocious
div>

It may be, but I think it is worth explicitly mentioning in the spec.

[frivoal]

I think this is mostly defined.

Side note 1: your example needs overflow to be set to something other than visible, otherwise text-overflow does not apply.

Side note 2: your example needs a second line of text in the div, otherwise max-lines:1 does nothing, and if there's no break, block-overflow: ellipsis does nothing.

Assuming we have more than 1 line's worth of content, and non-visible overflow:

• If there is a line breaking opportunity (e.g. supercalifragilisticexpialidocious is in the hyphenation dictionary, and hyphenation is turned on), we make break there, making room for the ellipsis. Therefore nothing overflows, and text-overflow does not have a chance to apply.
• If there isn't a line breaking opportunity (or there is one, but it is too late in the line to leave enough room for the ellipsis), we remove the entire content of the line to make room for the ellipsis. Therefore nothing overflows, and text-overflow does not have a chance to apply.

The only problem is if the ellipsis string itself is longer than the line. The spec says:

If the block overflow ellipsis is too long to fit in the line, the result is undefined. (The UA may, for example, treat the block overflow ellipsis as an unbreakable string, or it may lay out the string across more than one line, replacing content in earlier lines as well.)

I think this idea of replacing content in earlier lines, while nice, would bring it a lot of complexity, and that undefined behavior isn't helpful here.

I'd suggest switching to

The UA must treat the block overflow ellipsis as an unbreakable string. Therefore, if it is too long to fit in the line, it overflows. It's rendering is affected by the overflow and text-overflow properties.

That makes the whole thing much simpler and fully defined, and sufficient to handle the primary use case of this feature.

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.

cc: @fantasai What do you think?

[css-meeting-bot]

The CSS Working Group just discussed block-overflow and text-overflow, and agreed to the following:

• RESOLVED: text-overflow affects non-breakable portions of the block-overflow string

The full IRC log of that discussion

topic: block-overflow and text-overflow
github: https://github.com//issues/2882
florian: so the issue is about whether their interaction is well-defined. There's only one case where it's not defined.
florian: if you have a break opportunity during the line we'll insert the ellipsis after that break opportunity and block-overflow doesn't have the chance to apply
florian: the only case where it's not defined is where the ellipsis is longer than the whole line, right now the spec doesn't define it
florian: seems like we don't want the ellipsis to climb the line back up, so for now I think we should go for 'when the ellipsis is longer than the line then it does overflow, and text-overflow must apply'
tantek: I think we need an example that we could look up
florian: it's something like a very narrow paragraph with a very long block-overflow ellipsis
florian: the spec says that if block-overflow ellipsis overflows then it may overflow to the next line, but it's undefined
tantek: any implementation experience?
tantek: we should construct some examples and experiment, keeping the issue open for now
tantek: rather than spec something that is not easy to implement
It seems like "use multiple lines for the block-overflow indicator" is probably the better behavior from a user perspective, but it does seem hard to implement.
fantasai: seems fine to leave it open as people implement it
florian: so I'd expand on the proposal with examples in the issue
florian: I'm ok with that
dbaron: [what he wrote above]
dbaron: saying that it needs to fit on one line definitely makes implementation easier, but it's not clear how much
tantek: I'd prefer to specify the better behavior for the user, and we don't know how much harder it is
fantasai: so what we're hearing is that we should the issue open to wait for block ellipsis breaking across multiple lines, but we probably should say that if the block-overflow string still doesn't fit withing the block then text-overflow applies in that case as it would to any other text
astearns: I like the idea of working out concrete examples so that people get better idea, but also so that we can put them in the spec
florian: does it sound reasonable to resolve on what fantasai said and add examples for the block-ellipsis on multiple lines?
fantasai: I think we should resolve that text-overflow applies to the overflow string if there's an unbreakable string on it like it does to the rest
fantasai: also that we should put some example in the spec about this interaction, and also on the issue about what happens if the block-overflow string can break
fantasai: we could narrow down the behavior as 'either you treat is as unbreakable' or 'treat it as breakable and grab space from previous lines'
astearns: so the first bit is to resolve that text-overflow affects overflowing, unbreakable portions of the block-overflow string. objections?
RESOLVED: text-overflow affects non-breakable portions of the block-overflow string
astearns: probably the examples doesn't need a resolution
astearns: we're going to work on those to put them on the spec
florian: I'm going to put examples in the spec on what we just resolved, and then in the issue about the wrapping
astearns: should that be a different issue?
florian: maybe, sounds reasonable
astearns: we'll leave it to your discretion
florian: should we resolve on the breaking to narrow it down to the two discussed options?
astearns: don't care
florian: I think I prefer to leave as-is for now
florian: then we can narrow if we don't resolve soon
astearns: I think that's reasonable, I prefer to resolve soon, the examples would be really helpful