[css-overflow] Consider support for multiple-line ellipsis

[phistuck]

https://drafts.csswg.org/css-overflow/
Like text-overflow: -o-ellipsis-lastline, or -webkit-line-clamp did. Details at http://stackoverflow.com/questions/6572330/is-it-possible-to-use-text-overflowellipsis-on-multiline-text

[frivoal]

This is being considered, but this is a surprisingly difficult problem to solve well. The existing solutions you refer to work in some simple cases, and fall apart in the general case.

The eventual solution is expected to use the max-lines property and the continue property (possibly renamed) to define where your content should be cut, and what happens to the remaining part after the cut, and probably a (yet to be specified) pseudo element to define what gets inserted to show the ellipsis.

[RByers]

Note that apparently a huge amount of the mobile web depends on webkit-line-clamp (we see it used on 15% of page views on Android). @miketaylr says this is one of the top web compat issues in Firefox, and so I've re-opened a chromium bug saying that (if we can't remove it) we need to specify our behavior somewhere. @tabatkins said awhile back he'd be happy to help with this.

Should we work on this in css-overflow, or would it make more sense first to just try to document the existing WebKit/blink -webkit-line-clamp behavior in the compat spec?

[tabatkins]

So I've spent some time thinking about this in the past. I think there are two modes that people realistically want when clamping, which end up being quite distinct:

1. I want to display N lines of content, however large that ends up being. This should affect the layout size of the element, so it'll tightly fit the content (aka make it act like it was always filled with just N lines of content, no more).

2. I want to lay out an element normally, but if this would overflow, instead clamp to the largest number of lines possible without overflowing. (And size the element as if it were overflowing; that is, make it as large as possible, even if that leaves some empty space in the content area.)

The former is easy and simple, and basically what -webkit-line-clamp does. We should be able to port over its functionality into a spec for this pretty simply, I think.

The second is closer to what people often actually want, and approximate by just guessing at the number of lines that'll display in the space they have. Maybe it's a type of overflow-style value? I dunno.

[RByers]

Thanks Tab. Given how much usage of -webkit-line-clamp there is, it's really only (1) that I consider urgent here. Even though it's not ideal and we might not choose to ship such a new API now without also doing (2), that ship has effectively sailed - might as well document and test that as a first step, then (if it's important enough) iterate on improving and extending it.

[tabatkins]

I'm in agreement with this; the two can definitely ship separately, even if the first one isn't actually what's desired a lot of the time. It's Good Enough© for a first pass.

[RByers]

Excellent, thanks Tab!

So you'll work on a proposed change to css-overflow for this? Presumably you'll follow the typical CSSWG style of defining it as line-clamp and then we'll add an entry to the compat spec requiring -webkit-line-clamp as an alias, right?

Or since the existing API isn't exactly what people often want, would it be better to just define -webkit-line-clamp here, leaving the better line-clamp available? Or we could even choose a clearly poor but un-prefixed name for the CSS spec like legacy-line-clamp or line-count-clamp?

[fantasai]

I think ideally, it would make more sense to spec this feature as equivalent to max-height, except with the ability to specify that height in terms of number of lines.

This would require using overflow: hidden in conjunction with the property in order to actually hide the lines, but that would then give the author the control to make those lines visible with overflow: scroll or, in the future, to paginate them to another fragmentainer.

So, basically, I'm agreeing with Florian about the direction to go in, but to solve the cases that -webkit-line-clamp currently solves, we don't need the additional fragmentation support, just the max-lines property itself. If there's no strong compat restriction that will require us to exactly duplicate -webkit-line-clamp, then I think this is a better direction to go in: the behavior is simple to define in terms of existing CSS models, and it is extensible to behaviors we want to allow in the future, like stying the first N lines specially.

[frivoal]

I think ideally, it would make more sense to spec this feature as equivalent to max-height, except with the ability to specify that height in terms of number of lines.

This would require using overflow: hidden in conjunction with the property in order to actually hide the lines, but that would then give the author the control to make those lines visible with overflow: scroll or, in the future, to paginate them to another fragmentainer.

Basically, I think that's what -webkit-line-clamp does except that:

• it requires display: -webkit-box and -webkit-box-orient: vertical to be set as well, or it does not take effect (wtf?)
• it also adds "…" at the end of the last (non overflowing) line.

I suppose we can work around the first part by some clever aliasing strategy that (for web compat reasons) continues to require the odd properties and values to be set when using this feature under the -webkit-line-clamp name, and not when used under the max-lines name.

When max-lines is used together with the (not yet existing) fragmentation property, it probably should not affect the height, and let that continue to be a separate thing, but I suppose we can make that behavior depend on whether the fragmentation property is used.

I am not even sure that we have to skip making it depend on fragmentation. Fragmentation (especially if we're going to discard the remaining content) is pretty well defined and supported already. If Web compat allows (which is far from a given), we could probably handle making max-lines imply continue: discard. That's not the hard part of this property: continue: fragments is, and that can be implemented later. But if that's either too complex, or undesirable as a default, I agree that it is possible to not have this connection.

On the other hand, inserting the ellipsis is probably trickier. webkit-line-clamp's ellipsis rightfully appears to be smarter than text-overflow: ellipsis, but defining exactly how it works is probably going to be interesting if we want to make it robust (interactions with floats, atomic inlines, nested blocks, font changes, ::after, transforms...). And even if in the first pass we are happy with just inserting an inert "…", we need to keep in mind that people also have usecases both for making this interactive ("click here for more"), and for using structured & stylable content instead of the "…".

I suppose this is fine though. We can just imply that the current limited ellipsis is the result of something like a max-lines-ellipsis property being auto (and possibly also introduce a none value while we're at it), and that whatever alternative better system we come up later will just build from there.

[SebastianZ]

May I mention the use case for cropping contents in the middle again?

See https://www.w3.org/wiki/Text-overflow_middle_cropping and the discussions around it on www-style.

Sebastian