Re: [csswg-drafts] [css-overflow] Consider support for multiple-line ellipsis

> we wanted browsers to do the full thing, [...] and that doing it as a visual replacement was a tolerable approximation

There is a third option -- make the ellipsis cause a line break but render it the same as a `text-overflow` ellipsis (in **all** cases). This would allow us to reuse existing code for the rendering part. Something like this:
1. flow the block as if `block-overflow` doesn't exist
2. if it caused overflow, then shorten the available space to accommodate the size of an ellipsis and flow the last line again
3. repeat 2 until there is no additional overflow or the line is empty
4. during painting, render an ellipsis in the reserved space in the last line (same as a `text-overflow` ellipsis)

> If it is in the first lines (e.g. max-lines:1), then it should take the styles that affect the first line.

OK, but I disagree that that follows from "placed [...] as a direct child of the block container’s root inline box". It really is necessary to point that out explicitly if that's the behavior you intended.
Please note that `list-style-position:inside` `::marker` boxes does **not** affect `::first-letter/line` in current implementations, fwiw.

Anyway, the problem with the `::first-*` pseudos is that some UAs construct boxes for them in the box construction phase, which happens before the layout phase, so if the inserted ellipsis should be affected by these styles then it might affect boxes that were already constructed.  For example, if the ellipses is so wide that it requires the entire length of the line then any existing `::first-letter/line` boxes needs to be undone somehow.  For `::first-letter` there's also the case where leading punctuation on the line should be included together with the first character of the ellipsis.  The implementation of these pseudos is already quite messy (and buggy) in Gecko and I suspect that might be the case for other UAs too. This is why I'm asking for a detailed spec about how the interaction (or not) between these boxes should work, because otherwise we'll almost certainly end up with incompatible implementations.

I would strongly prefer to keep the `block-overflow` property simple though, i.e. not interacting with boxes other than shortening the last line.  We can introduce a more general "`::fragment-before/::fragment-after`"  in the future, that would magically appear at fragmentation boundaries (possibly with additional conditions that an author can control).  For example, it's quite common in printed newspapers to insert a "continued from page N" at the _start_ of a fragment when it continues from an earlier page.

> I suspect there's a significant difference in implementation complexity between treating as an unbreakable string that overflows and climbing back up the previous lines.

Indeed, and I suspect the estimated size of the ellipses as a single line is likely too small if it needs line breaks after being inserted. An ellipses that doesn't fully fit on the last line is an edge case anyway, so I think it's ok to restrict its layout heavily to simplify implementations.

-- 
GitHub Notification of comment by MatsPalmgren
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/390#issuecomment-372302097 using your GitHub account

Received on Monday, 12 March 2018 13:04:08 UTC