[css-overflow-4] How do -webkit-line-clamp and line-clamp interact when both are specified?

[andreubotella]

In the current spec text for css-overflow-4, which only describes continue: discard (not yet continue: collapse as described in #7708), both line-clamp and the legacy -webkit-line-clamp property are shorthands for other properties, including max-lines. This means that if both are specified on some element, whichever wins in the cascade will be applied.

However, this leads to unexpected results. Consider the following:

display: block;
line-clamp: 3;
-webkit-line-clamp: 4;

Since line-clamp and -webkit-line-clamp are shorthands for the same set of properties, -webkit-line-clamp will win. This means that max-lines will have a specified value of 4, but also that continue will have a specified value of -webkit-discard – which will cause the continue property (and by extension, max-lines) to not take effect, because display is not set to -webkit-box.

My current implementation of continue: collapse in Blink (see #7708) implements both line-clamp and -webkit-line-clamp as longhands which don't alias. If both are present (and not specified to none) on some box, line-clamp wins. AFAIU this behavior wouldn't be possible to specify while making (-webkit-)line-clamp shorthands, unless we make a separate -webkit-max-lines property.

If we want to keep the shorthands, while making the code above actually work, my understanding is that -webkit-line-clamp would have to be specified such that it sets the longhands if display: -webkit-box and -webkit-box-orient: vertical are set, and to not be a shorthand for anything otherwise.

cc @frivoal

[frivoal]

Since line-clamp and -webkit-line-clamp are shorthands for the same set of properties, -webkit-line-clamp will win. This means that max-lines will have a specified value of 4, but also that continue will have a specified value of -webkit-discard – which will cause the continue property (and by extension, max-lines) to not take effect, because display is not set to -webkit-box.

That doesn't bother me: there really isn't a point in going around setting -webkit-line-clamp on elements which do not have the -webkit-box and -webkit-box-orient preconditions. And since #10324 (comment), the unprefixed line-clamp also blockifies -webkit-box when -webkit-box-orient is there too, so there's no need to do it manually. In other words, for a new site that's not trying to activate legacy browsers, there's no reason to have -webkit-line-clamp at all, and for a site that wants to target old and new browsers, there should be -webkit-line-clamp as well as -webkit-box and -webkit-box-orient.

My current implementation of continue: collapse in Blink (see #7708) implements both line-clamp and -webkit-line-clamp as longhands which don't alias. If both are present (and not specified to none) on some box, line-clamp wins.

I think it's more typical for CSS to have the cascade order determine the winner.

If we want to keep the shorthands, while making the code above actually work, my understanding is that -webkit-line-clamp would have to be specified such that it sets the longhands if display: -webkit-box and -webkit-box-orient: vertical are set, and to not be a shorthand for anything otherwise.

You could do that, but conditional shorthands seem unusual. Might be tricky to implement.

I think the following alternative would work, without the full set of longhands:

You could have some simplified version of the longhands, not exposed to web authors. One would have to be continue: auto | discard | -webkit-discard, but the other could be a simplified combination of max-lines and block-ellipsis, which basically means having the same value space as line-clamp.

cc: @fantasai

[Loirooriol]

It it sets the longhands if display: -webkit-box and -webkit-box-orient: vertical are set, and to not be a shorthand for anything otherwise.

Note that we need to expand shorthands into longhands at parse time, but we may not know the value of display until computed-value time (e.g. when using variables).

Also I don't think a property should sometimes be a longhand and sometimes a shorthand, that would be problematic e.g. because [...getComputedStyle()] only includes longhands.

Like Florian says I think it's fine if -webkit-line-clamp wins over a preceding line-clamp.

[andreubotella]

There is a 4% of page loads where -webkit-line-clamp is specified and does nothing because the other properties aren't set. This is likely because it was set once in some selectors and then forgotten about. I worry that if some new selectors are added which use line-clamp, and there are cases where both selectors apply to the same element, the fact that line-clamp might not take effect either would be completely unexpected.

But maybe making sure that the devtools show indications about this would be enough to make this not an issue.