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

> 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.

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

Received on Friday, 18 August 2017 08:43:18 UTC