[css-overflow-4] `line-clamp` shorthand syntax is ambiguous

[andreubotella]

Currently the syntax for the line-clamp property is none | [<integer [1,∞]> || <'block-ellipsis'>] -webkit-legacy?. The none branch at the left of the bar (|) sets all three longhands to their initial values. However, none is also a valid value for the right hand of the bar, since it's a valid value for the block-ellipsis property; and that would set continue to its non-initial collapse value.

The none left branch probably needs to keep that name for compatibility with -webkit-line-clamp¹. But we probably want to be able to represent continue: collapse; max-lines: none; block-ellipsis: none with some shorthand. So should we find some other keyword for the block-ellipsis value where there's no ellipsis? Note that the declarations line-clamp: none 3 or line-clamp: none -webkit-legacy might be confusing to developers, especially since setting the block-ellipsis value might be uncommon.

cc @frivoal @emilio @bfgeek

Footnotes

1. Well, traditionally, at least Webkit and Chromium's implementation of -webkit-line-clamp didn't support the none keyword as an input, and also didn't support any other way to input the initial state of that property other than with initial; although they did output none when serializing the property 🤷. But this has been fixed over the past few years, and currently all mainstream browsers will accept -webkit-line-clamp: none. ↩

[frivoal]

I think the easiest way is to simply drop the none value from block-ellipsis. Its usage is likely to be rare, and people who want that effect can specify the empty string anyway.

[andreubotella]

In Chromium, we were considering shipping line-clamp with the only allowed values for block-ellipsis being none or auto, and only working on adding string values afterwards. After all, not having an ellipsis is easier than having one implementation-wise, and there are still some significant open issues for block-ellipsis: <string> (e.g. #11660, #11683) that should be looked at before any browser ships it.

[frivoal]

I can think of 5 alternatives:

1. drop none from block-ellipsis, authors can get the same effect with "". Downside: empty-string block ellipsis is simpler to implement than arbitrary string block ellipsis, so it's unfortunate to need the complex system to be able to do the simple thing, and there's a good chance Chrome or other browsers would initially only ship block-ellipsis: auto initially, with no possibility to turn things off.
2. rename none from block-ellipsis to something else. Downside: that's a pretty good name for what it does, not sure what else would work. empty? no-ellipsis? blank?
3. rename none from max-lines to something else. Downside: that's a pretty good name for what it does, not sure what else would work.
4. change the shorthand fro none | [<integer [1,∞]> || <'block-ellipsis'>] -webkit-legacy? to none | [<integer [1,∞]> || <'block-ellipsis'> || <'continue'>] , with continue being set to collapse when omitted, unless we're in the single none senario, in which case it is set to auto. Downside: now we have an ambiguity between auto in the shorthand meaning continue: auto or block-ellipsis: auto if the other is omitted.
5. No change. Downside: continue: collapse; max-lines: none; block-ellipsis: none cannot be expressed with the shorthand.

Another shared downside of (4) and (5) is that none and none none don't mean the same thing (first one maps continue to auto, second one to collapse).

I think I favor option 1 (as mentioned previously) because it the long run, it seems like the least intrusive. But 2 or 3 would be nice if we could just find a good name.

[andreubotella]

3. rename none from max-lines to something else. Downside: that's a pretty good name for what it does, not sure what else would work.

In isolation, I think a better keyword would be auto (since the value of max-lines is ignored if we're not clamping, and when it's set to none it clamps to however many lines will fit on the line-clamp container). But in the shorthand that would also be ambiguous with block-ellipsis: auto.

4. change the shorthand fro none | [<integer [1,∞]> || <'block-ellipsis'>] -webkit-legacy? to none | [<integer [1,∞]> || <'block-ellipsis'> || <'continue'>] , with continue being set to collapse when omitted, unless we're in the single none senario, in which case it is set to auto. Downside: now we have an ambiguity between auto in the shorthand meaning continue: auto or block-ellipsis: auto if the other is omitted.

I don't think this is a good idea, because if continue is set to auto, then there's no clamping, and the other two longhands are irrelevant. So you'd have line-clamp: none and line-clamp: 3 auto behaving the same.

---

Looking at the options, I think (1) would probably be the best choice long-term. And since it doesn't seem like block-ellipsis: none would be used that much, it might be fine for Chrome and other browsers to not allow turning off the ellipsis at first.

[Loirooriol]

empty-string block ellipsis is simpler to implement than arbitrary string block ellipsis, so it's unfortunate to need the complex system to be able to do the simple thing

Browsers could accept "" while rejecting any other string (as an initial implementation). That may be confusing for authors, though.