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

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-4] How do `-webkit-line-clamp` and `line-clamp` interact when both are specified?, and agreed to the following:

• RESOLVED: Add a "-webkit-legacy" value to line-clamp, and define -webkit-line-clamp to be a shorthand of line-clamp that adds the keyword

The full IRC log of that discussion

<TabAtkins> andreubotella: usually when you have -webkit prefixes they're alias or legadcy shorthand
<TabAtkins> andreubotella: so there's always a way to replace the -webkit prefix with the modern one
<TabAtkins> andreubotella: even if the parsing is different
<TabAtkins> andreubotella: this is not the case for -webkit-line-clamp, due to web compat constraints
<TabAtkins> andreubotella: -webkit-line-clamp only works with -webkit-box and vertical on the same element
<TabAtkins> andreubotella: over 4% of page laods are using it wrong and we'd change their behavior if we changed this
<TabAtkins> andreubotella: so what happens if you set both on the same element?
<TabAtkins> andreubotella: currently they're both defined as shorthands over some longhands, including 'continue'
<TabAtkins> andreubotella: the keyword of 'continue' that triggers the legacy behavior is "continue: -webkit-discard"
<TabAtkins> andreubotella: and a similar "-webkit-collapse"
<TabAtkins> andreubotella: so if you ahve "line-clamp: 3; -webkit-line-clamp: 4", then "continue" will have -webkit-discard
<florian> q+
<TabAtkins> andreubotella: so even tho the unprefixed version is set, it'll still require -webkit-box
<TabAtkins> andreubotella: do we want this behavior?
<TabAtkins> andreubotella: there's also the fact that in chromium this is only possible to implement if we actually have the longhands
<TabAtkins> andreubotella: but we've said the longhands must not be web-exposed currently. this would require changing chrome's property reoslution. not insurmountable, but I'd like to not do it, it's new territory
<astearns> ack florian
<emilio> q+
<TabAtkins> florian: indeed, we say in the spec that this is defined in terms of shorthand/longhands, but dont' expose the longhands yet
<TabAtkins> florian: the intent when we did it wasn't that the longhands were wrong, but that we thought the shorthand was good and we wanted room to tweak the longhands
<TabAtkins> florian: but the interaction of th eprefixed and unprefixed do happen in the longhands
<TabAtkins> florian: so we either need to expose some interaction, or double down
<TabAtkins> florian: assuming we can get longhand to work, the situation that Andreu is concerned about is that you have both versions set, and the prefixed version is last in cascade, and you don't have the legacy special properties that make the legacy version work
<TabAtkins> florian: you start with line-clamp:3, then you add the -webkit-line-clamp one, and you lose clamping entirely
<TabAtkins> florian: i think that's ok? if you don't want it, don't have the legacy thing last on the cascade
<TabAtkins> florian: there are a bunch of websites that have the legacy and it works, and a bunch that have the legacy and it doesn't work and they need it to not work
<TabAtkins> florian: but at the point where you also have the new syntax, that's where you need to be careful. yo udon't add the new syntax with the intent that it doesn't work
<TabAtkins> florian: it's a little weird, but i think it's fine
<TabAtkins> florian: so do we want to double-down on the longhand syntax, do we really want non-exposed longhands, or do we want to change how we define this?
<TabAtkins> fantasai: it's comitting to the longhands ahving independent effects
<TabAtkins> fantasai: if you just specify max-lines and not the others, will that have an effect?
<TabAtkins> fantasai: i think we want to go there ultimately, whatever we decide ehre has to be compatible
<TabAtkins> fantasai: so we'd have to expose each longhadn
<TabAtkins> florian: if we think we want to go there but we're not ready, maybe go for private longhand version
<astearns> ack emilio
<TabAtkins> emilio: it feels weird - it's unfortunate that we can't just make -webkit-line-clamp an alias, that sucks
<fantasai> s/it's comitting/it's not just committing to the syntax, but also /
<TabAtkins> emilio: but it feels like this should be implementable without having weird internal longhands, if we add the ability to specify the legacy behavior to 'line-clamp'
<fantasai> s/will that have an effect?/then that needs to have its intended effect/
<TabAtkins> emilio: and that seems workable
<TabAtkins> emilio: that way -webkit-line-clamp would just be a shorthand of line-clamp in the interim
<TabAtkins> florian: i think that would work
<TabAtkins> emilio: that seems fairly easy to implement
<TabAtkins> emilio: prevents having two longhands that do different things that interact weirdly
<TabAtkins> emilio: it might be a keyword or something at the end of 'line-clamp', it causes the weird legacy stuff
<fantasai> +1 emilio
<TabAtkins> emilio: i think that's simpler and doesn't preclude us from breaking down line-calmp into shorthands in the future
<TabAtkins> florian: agree
<TabAtkins> +1 as well
<TabAtkins> andreubotella: i want to be careful that the syntax - in the utopian case where we can remove the legacy behavior, we want this legacy syntax to still work
<TabAtkins> andreubotella: that would still require implementing the legacy syntax in engines
<TabAtkins> emilio: that's the same as can we ever remove continue:-webkit-discard
<TabAtkins> florian: either people are not using it anymore and we can remove it regardless of syntax, or they are using it and we can't remove it regardless of syntax
<emilio> q+ to reply to fantasai
<TabAtkins> fantasai: is this flag actualy something in the syntax that an author can specify, or is it just something we store internally? it woudln't strictly round trip
<astearns> ack emilio
<Zakim> emilio, you wanted to reply to fantasai
<TabAtkins> florian: think we can keep it simple, just slap a legacy keyword on it
<TabAtkins> emilio: yeah unless this is partiuclarly annoying, i think we should just add a keyword to the syntax so it round trips
<TabAtkins> emilio: too many things that iterate over properties and copy them, would be weird if that didn't work
<TabAtkins> emilio: so if you copied the computed display value...
<florian> q+
<TabAtkins> emilio: display and line-clamp, it wouldn't work
<TabAtkins> emilio: you'd put a standard line-clamp on a -webkit-box
<astearns> ack florian
<TabAtkins> florian: I suggest we just make the keyword sipmle and not magic
<TabAtkins> florian: there's no good reason for people to directly use it. it'll trigger from teh prefixed proeprty; people could write it themselves but why woudl they
<TabAtkins> florian: the only thing you get from this keyword is the requirement to also set these other stupid properties
<TabAtkins> TabAtkins: agree, we can just give it a dumb name
<TabAtkins> andreubotella: and make sure it's listed as deprecated in MDN to help push authors away
<TabAtkins> astearns: so if an author specifies line-clamp, then after specifies -webkit-line-clamp, it still won't clamp becuase the other properties aren't set
<TabAtkins> astearns: but the value of line-clamp is set to the legacy thing. we're just specifying the interaction and making it as normal as possible wrt the cascade
<TabAtkins> astearns: proposed resolution: Add a "legacy" value to line-clamp, and define -webkit-line-clamp to be a shorthand of line-clamp that adds the keyword
<TabAtkins> fantasai: can it be a -webkit prefix? make it ugly?
<TabAtkins> TabAtkins: yeah let's
<TabAtkins> -webkit-legacy
<fantasai> s/ugly/obviously linked to the -webkit- weirdness/
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: Add a "-webkit-legacy" value to line-clamp, and define -webkit-line-clamp to be a shorthand of line-clamp that adds the keyword
<TabAtkins> astearns: there's no problem with line-calmp resetting -webkit-line-clamp to its initial value?
<TabAtkins> florian: [shrugs]
<TabAtkins> fantasai: since line-calmp is a shorthand of continue, and in the longhandy version of this the weirdness is tied to a -webkit-* keyword...
<TabAtkins> florian: we're speccing two versions in parallel right now, a collapse and a discard
<TabAtkins> florian: we're about to switch from discard to collapse
<TabAtkins> florian: jsut havent' decided it yet
<TabAtkins> fantasai: well my point was going to be to use that keyword name, since that's usually how keywords work, but sounds complicated. never mind