- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Apr 2025 14:00:49 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> andreubotella: usually when you have -webkit prefixes they're alias or legadcy shorthand<br> <TabAtkins> andreubotella: so there's always a way to replace the -webkit prefix with the modern one<br> <TabAtkins> andreubotella: even if the parsing is different<br> <TabAtkins> andreubotella: this is not the case for -webkit-line-clamp, due to web compat constraints<br> <TabAtkins> andreubotella: -webkit-line-clamp only works with -webkit-box and vertical on the same element<br> <TabAtkins> andreubotella: over 4% of page laods are using it wrong and we'd change their behavior if we changed this<br> <TabAtkins> andreubotella: so what happens if you set both on the same element?<br> <TabAtkins> andreubotella: currently they're both defined as shorthands over some longhands, including 'continue'<br> <TabAtkins> andreubotella: the keyword of 'continue' that triggers the legacy behavior is "continue: -webkit-discard"<br> <TabAtkins> andreubotella: and a similar "-webkit-collapse"<br> <TabAtkins> andreubotella: so if you ahve "line-clamp: 3; -webkit-line-clamp: 4", then "continue" will have -webkit-discard<br> <florian> q+<br> <TabAtkins> andreubotella: so even tho the unprefixed version is set, it'll still require -webkit-box<br> <TabAtkins> andreubotella: do we want this behavior?<br> <TabAtkins> andreubotella: there's also the fact that in chromium this is only possible to implement if we actually have the longhands<br> <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<br> <astearns> ack florian<br> <emilio> q+<br> <TabAtkins> florian: indeed, we say in the spec that this is defined in terms of shorthand/longhands, but dont' expose the longhands yet<br> <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<br> <TabAtkins> florian: but the interaction of th eprefixed and unprefixed do happen in the longhands<br> <TabAtkins> florian: so we either need to expose some interaction, or double down<br> <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<br> <TabAtkins> florian: you start with line-clamp:3, then you add the -webkit-line-clamp one, and you lose clamping entirely<br> <TabAtkins> florian: i think that's ok? if you don't want it, don't have the legacy thing last on the cascade<br> <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<br> <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<br> <TabAtkins> florian: it's a little weird, but i think it's fine<br> <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?<br> <TabAtkins> fantasai: it's comitting to the longhands ahving independent effects<br> <TabAtkins> fantasai: if you just specify max-lines and not the others, will that have an effect?<br> <TabAtkins> fantasai: i think we want to go there ultimately, whatever we decide ehre has to be compatible<br> <TabAtkins> fantasai: so we'd have to expose each longhadn<br> <TabAtkins> florian: if we think we want to go there but we're not ready, maybe go for private longhand version<br> <astearns> ack emilio<br> <TabAtkins> emilio: it feels weird - it's unfortunate that we can't just make -webkit-line-clamp an alias, that sucks<br> <fantasai> s/it's comitting/it's not just committing to the syntax, but also /<br> <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'<br> <fantasai> s/will that have an effect?/then that needs to have its intended effect/<br> <TabAtkins> emilio: and that seems workable<br> <TabAtkins> emilio: that way -webkit-line-clamp would just be a shorthand of line-clamp in the interim<br> <TabAtkins> florian: i think that would work<br> <TabAtkins> emilio: that seems fairly easy to implement<br> <TabAtkins> emilio: prevents having two longhands that do different things that interact weirdly<br> <TabAtkins> emilio: it might be a keyword or something at the end of 'line-clamp', it causes the weird legacy stuff<br> <fantasai> +1 emilio<br> <TabAtkins> emilio: i think that's simpler and doesn't preclude us from breaking down line-calmp into shorthands in the future<br> <TabAtkins> florian: agree<br> <TabAtkins> +1 as well<br> <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<br> <TabAtkins> andreubotella: that would still require implementing the legacy syntax in engines<br> <TabAtkins> emilio: that's the same as can we ever remove continue:-webkit-discard<br> <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<br> <emilio> q+ to reply to fantasai<br> <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<br> <astearns> ack emilio<br> <Zakim> emilio, you wanted to reply to fantasai<br> <TabAtkins> florian: think we can keep it simple, just slap a legacy keyword on it<br> <TabAtkins> emilio: yeah unless this is partiuclarly annoying, i think we should just add a keyword to the syntax so it round trips<br> <TabAtkins> emilio: too many things that iterate over properties and copy them, would be weird if that didn't work<br> <TabAtkins> emilio: so if you copied the computed display value...<br> <florian> q+<br> <TabAtkins> emilio: display and line-clamp, it wouldn't work<br> <TabAtkins> emilio: you'd put a standard line-clamp on a -webkit-box<br> <astearns> ack florian<br> <TabAtkins> florian: I suggest we just make the keyword sipmle and not magic<br> <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<br> <TabAtkins> florian: the only thing you get from this keyword is the requirement to also set these other stupid properties<br> <TabAtkins> TabAtkins: agree, we can just give it a dumb name<br> <TabAtkins> andreubotella: and make sure it's listed as deprecated in MDN to help push authors away<br> <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<br> <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<br> <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<br> <TabAtkins> fantasai: can it be a -webkit prefix? make it ugly?<br> <TabAtkins> TabAtkins: yeah let's<br> <TabAtkins> -webkit-legacy<br> <fantasai> s/ugly/obviously linked to the -webkit- weirdness/<br> <TabAtkins> astearns: objections?<br> <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<br> <TabAtkins> astearns: there's no problem with line-calmp resetting -webkit-line-clamp to its initial value?<br> <TabAtkins> florian: [shrugs]<br> <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...<br> <TabAtkins> florian: we're speccing two versions in parallel right now, a collapse and a discard<br> <TabAtkins> florian: we're about to switch from discard to collapse<br> <TabAtkins> florian: jsut havent' decided it yet<br> <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<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10439#issuecomment-2772661772 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 April 2025 14:00:51 UTC