Re: [csswg-drafts] [css-overflow-4] How do `-webkit-line-clamp` and `line-clamp` interact when both are specified? (#10439)

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: Confirm that -webkit-line-clamp should become a shorthand of line-clamp (unless we run into compat issue)`
* `RESOLVED: Remove the "hidden longhands" text for line-clamp's longhands, just make them normal longhands.`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> andreubotella: last time we discussed, we reoslved to add -webkit-legacy keyword to handle the prefixed property behavior<br>
&lt;TabAtkins> andreubotella: we'd previously resolved, or at least agreed, that it's not safe to change the longhand status of a proeprty without thinking about it. it's observable while iterating getcomputedstyle results<br>
&lt;TabAtkins> andreubotella: issue 8398 [might not have gotten that right]<br>
&lt;astearns> that is the issue<br>
&lt;TabAtkins> andreubotella: so do we want to make this a shorthand, or just an alias in getComputedStyle?<br>
&lt;TabAtkins> andreubotella: either way, result won't undo the previous resolution, just clarifying how to expose it<br>
&lt;florian> q+<br>
&lt;TabAtkins> andreubotella: also question of how to expose the unprefixed line-clamp as a longhand. currently defined as a shorthand whose longhands arent' exposed. shoudl it be a shorthand from the get-go?<br>
&lt;TabAtkins> andreubotella: if so, especially if -webkit-line-clamp is also a shorthand, there will be no longhands in the cssStyleDeclaration data model. it only contains longhands, and computes shorthands on the fly.<br>
&lt;TabAtkins> andreubotella: so do we ship -webkit-line-clamp as a shorthand, and what do we do about line-clamp<br>
&lt;astearns> ack florian<br>
&lt;TabAtkins> florian: i think -webkit-line-clamp shoudl be a shorthand. yes, it's a change, and we should be careful. but it was non-standard, if we can't do that we're really stuck. making it a shorthand is more sensible and consistent overall. if there are actual compat problems we can talk about them, but this isn't a property we've had since forever (like 'position' was).<br>
&lt;TabAtkins> florian: question about longhands in general, when we drafted this initially we weren't sure of the syntax space. so we drafted something with the concern that we might need to change all the longhands up.<br>
&lt;TabAtkins> florian: so this was a temporary warning in the spec<br>
&lt;TabAtkins> florian: but the spec has been this way for a long time now, and we've revisited the feature a lot but the syntax has been stable.<br>
&lt;TabAtkins> florian: so at this point i think it's not useful to hide the longhands. so i think we should just act as normal now.<br>
&lt;TabAtkins> florian: the "dont' show" was never intended as something permanent<br>
&lt;andreubotella> q+<br>
&lt;astearns> ack andreubotella<br>
&lt;TabAtkins> andreubotella: thre is one thing in the shorthand behaviro that might not be clear or well-tested, which is inheritance of block-overflow<br>
&lt;TabAtkins> andreubotella: block-ellipsis, sorry<br>
&lt;TabAtkins> andreubotella: currently in my impl, it applies to the entire line-clamp container, and that defines whether the ellipsis would apply or not, and how<br>
&lt;TabAtkins> andreubotella: if that is equivalent to defining line-clamp as a shorthand as currently defined... i think we need to think more about the inheriting behavior and how to disable ellipsis for a particular para or something<br>
&lt;TabAtkins> andreubotella: i don't think it's a bad idea, but it's something folks might not be aware of<br>
&lt;TabAtkins> florian: i agree it's something to think of, but the intent of the spec is indeed to implement exactly the bheavior *as if* the longhands were there, so this problem is already there.<br>
&lt;TabAtkins> florian: if we want to talk about whether the behavior of one longhand should be changed, that's it's own issue.<br>
&lt;TabAtkins> florian: but the "hidden longhands" problem just opens up problems that aren't actually interesting to answer, and we should stop leaning on it<br>
&lt;TabAtkins> astearns: so first q is whether -webkit-line-clamp should become a shorthand<br>
&lt;TabAtkins> florian: we resolve don this before, but we hadn't consdiered about our other discussions about how changing longhands to shorthands is something with compat risk<br>
&lt;TabAtkins> astearns: so a proposed extra resolution to affirm our shorthand resolution, absent web compat<br>
&lt;TabAtkins> astearns: objections?<br>
&lt;TabAtkins> RESOLVED: Confirm that -webkit-line-clamp should become a shorthand of line-clamp (unless we run into compat issue)<br>
&lt;TabAtkins> florian: so the other resolution, remove the "hidden longhands" text and just spec them as nromal<br>
&lt;TabAtkins> astearns: that's okay with you andreu?<br>
&lt;TabAtkins> andreubotella: yes, tho I'd like to get emilio's opinion<br>
&lt;TabAtkins> astearns: so we can provisionally resolve to remove the hidden longhands text<br>
&lt;TabAtkins> astearns: objections?<br>
&lt;TabAtkins> RESOLVED: Remove the "hidden longhands" text for line-clamp's longhands, just make them normal longhands.<br>
&lt;fantasai> +1<br>
&lt;TabAtkins> astearns: i'll tag emilio<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-3005414084 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 25 June 2025 16:31:31 UTC