W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2018

Re: [csswg-drafts] [css-overflow] ensure interactions between block-overflow and text-overflow are defined

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Wed, 11 Jul 2018 09:02:45 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-404097915-1531299764-sysbot+gh@w3.org>
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 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?

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2882#issuecomment-404097915 using your GitHub account
Received on Wednesday, 11 July 2018 09:02:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 09:02:52 UTC