[css-overflow-4] Syntax to opt into clamping at the earlier of a size and a number of line

[frivoal]

In #12041, we decided that if you set both a max-line and n height or a max-height, only the number of lines affects clamping. ((max-)height affects the height, normally, but without changing what content gets clamped).

This was primarily driven by compat needs. We also said it'd be good to have an opt-in to clamp to the earlier of the (max-)height and the specified number of lines, we just need to find syntax for it. This issue is for discussing that.

[frivoal]

Skip to the bottom of this comment if you just want to see my proposal, and not how I got there.

The opt-in we're looking for is probably going to be surfaced as an extra keyword on the shorthand, but we need to figure out what the name of that value is, and which longhand it goes into.

As a reminder, the current syntax is:

block-ellipsis:		no-ellipsis | auto | <string>
continue:			auto | discard | collapse | -webkit-legacy
max-lines:			none | <integer [1,∞]>

with a shorthand of:

line-clamp:			none | [<integer [1,∞]> || <'block-ellipsis'>] -webkit-legacy?

and a legacy shorthand of:

-webkit-line-clamp:	none | <integer [1,∞]>

The only thing that has shipped in production so far is the legacy shorthand, so we can re-jiggle the rest if necessary (and if we do it quick, because this will likely be launching soon).

(In the rest of this message, for simplicity, I won't be mentioning the -webkit parts, as we're not changing them.)

There's something a little surprising about the current shorthand, which works well from an author point of view, but isn't wired the way most people think (at least in my impression): to get a line-count based clamp, you say line-clamp: 3, and to get a height-based clamp, you say line-clamp: auto. But the auto doesn't actually have anything to do directly with being height based. In fact, it's a value of block-ellipsis. What's really happening is that line-clamp: 3 is short for line-clamp 3 auto, and it's the absence of the number, not the presence of auto that makes line-clamp: auto activate the height based mode.

Either way, I don't think it would make sense to stuff the new keyword in block-ellipsis, even if auto deceptively appears to be what triggers the height based mode. However, we arguably could rename block-ellipsis: auto into something else if we wanted to reuse the auto somewhere else. block-ellipsis: ellipsis could be an option, especially given that this is the name of the corresponding value in text-overflow: ellipsis.

This leaves us with two candidates properties to host the new keyword (which may or may not be auto): max-lines and continue.

I don't think max-lines is a great fit: it's about lines, not about height. Also, clamping at the earlier point is only to be an opt-in for continue: collapse. The fragmentation-based mechanics of continue: discard have it work out by default. So since this really is a mode of continue: collapse, it probably should be a keyword next to collapse in the continue property.

---

All in all, I'd suggest:

• rename block-ellipsis: auto to block-ellipsis: ellipsis
• rename continue: auto to continue: normal (the auto name is a left-over of an earlier design anyway, where auto would compute to other values based on various things. See https://www.w3.org/TR/2024/WD-css-overflow-5-20241217/#channelling-overflow)
• add auto as an optional keyword alongside collapse in continue (think of it as "auto-height")
• continue is set to collapse auto if either there's auto in the shorthand or if there is no integer in the shorthand (or both) (edited from an earlier incomplete description)

The complete syntax would then look like (omitting the -webkit- parts, which don't change)

line-clamp:			none | [<integer [1,∞]> || auto || <'block-ellipsis'>]
block-ellipsis:		no-ellipsis | ellipsis | <string>
continue:			normal | discard | [collapse && auto?]
max-lines:			none | <integer [1,∞]>

Examples, to see if the syntax makes sense from a user's point of view, and what it expands to:

shorthand	longhand expansion	line-based clamping	height-based clamping	ellipsis
line-clamp: 3	continue: collapse; block-ellipsis: ellipsis; max-lines: 3;	✅	❌	…
line-clamp: 3 ellipsis
line-clamp: auto	continue: collapse auto; block-ellipsis: ellipsis; max-lines: none;	❌	✅	…
line-clamp: ellipsis
line-clamp: auto ellipsis
line-clamp: 3 auto	continue: collapse auto; block-ellipsis: ellipsis; max-lines: 3;	✅	✅	…
line-clamp: 3 auto ellipsis
line-clamp: "(continued)"	continue: collapse auto; block-ellipsis: "(continued)"; max-lines: none;	❌	✅	(continued)
line-clamp: auto "(continued)"
line-clamp: 3 "(continued)"	continue: collapse; block-ellipsis: "(continued)"; max-lines: 3;	✅	❌	(continued)
line-clamp: no-ellipsis	continue: collapse auto; block-ellipsis: no-ellipsis; max-lines: none;	❌	✅
line-clamp: 3 no-ellipsis	continue: collapse; block-ellipsis: no-ellipsis; max-lines: 3;	✅	❌

And so on. I think this works alright, so I suggest we do that.

[meyerweb]

Overall, this syntax largely makes sense to me and is relatively clear about what will happen, up to a point. I still have problems with the way this overrides (max-)height.; line-clamp says that it clamps, as in limits, not that it enforces.

So I guess I mean that this syntax seems relatively clear about what will happen as long as height is auto. In non-auto cases, it’s completely unclear about how other properties (height, max-height, I assume also (max-)block-size?) will be outright ignored.

[andreubotella]

Even if we're not changing -webkit-line-clamp, would continue: -webkit-legacy auto be a valid value? What about line-clamp: 3 auto -webkit-line-clamp?