-
Notifications
You must be signed in to change notification settings - Fork 704
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-overflow-4] How do -webkit-line-clamp
and line-clamp
interact when both are specified?
#10439
Comments
That doesn't bother me: there really isn't a point in going around setting
I think it's more typical for CSS to have the cascade order determine the winner.
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 cc: @fantasai |
Note that we need to expand shorthands into longhands at parse time, but we may not know the value of Also I don't think a property should sometimes be a longhand and sometimes a shorthand, that would be problematic e.g. because Like Florian says I think it's fine if |
There is a 4% of page loads where But maybe making sure that the devtools show indications about this would be enough to make this not an issue. |
The CSS Working Group just discussed
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 |
In the current spec text for css-overflow-4, which only describes
continue: discard
(not yetcontinue: collapse
as described in #7708), bothline-clamp
and the legacy-webkit-line-clamp
property are shorthands for other properties, includingmax-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:
Since
line-clamp
and-webkit-line-clamp
are shorthands for the same set of properties,-webkit-line-clamp
will win. This means thatmax-lines
will have a specified value of4
, but also thatcontinue
will have a specified value of-webkit-discard
– which will cause thecontinue
property (and by extension,max-lines
) to not take effect, becausedisplay
is not set to-webkit-box
.My current implementation of
continue: collapse
in Blink (see #7708) implements bothline-clamp
and-webkit-line-clamp
as longhands which don't alias. If both are present (and not specified tonone
) 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 ifdisplay: -webkit-box
and-webkit-box-orient: vertical
are set, and to not be a shorthand for anything otherwise.cc @frivoal
The text was updated successfully, but these errors were encountered: