- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 18 Feb 2026 17:28:51 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values] Add a way to set longhands to the corresponding expansion of a shorthand value`, and agreed to the following: * `RESOLVED: Start drafting a solution in css-values-5` <details><summary>The full IRC log of that discussion</summary> <oriol> https://docs.google.com/presentation/d/1HJoIC-RFcPjFjSzjYOW440bqESXGs2CqVbwTxzRqX-0/edit?slide=id.p1#slide=id.p1<br> <emilio> oriol: [presents slides, similar as the issue]<br> <emilio> q+<br> <astearns> Zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <astearns> q+ emilio<br> <emilio> (FWIW the servo representation of this is basically identical: https://searchfox.org/firefox-main/rev/150ca809c7243bd6e994f28cc4a3750430783364/servo/components/style/properties/mod.rs#1400)<br> <lea> q?<br> <flackr> q+<br> <astearns> q+<br> <emilio> astearns: what's the other issue?<br> <emilio> oriol: #11055<br> <emilio> emilio: Q: should this have the same "unparsed value" semantics as variables? I.e. should `margin-top: from-shorthand(margin: garbage);` be invalid at parse time?<br> <astearns> ack emilio<br> <lea> +1, love this<br> <emilio> emilio: generally supportive<br> <emilio> ... would this be only valid as a whole declaration value?<br> <emilio> ... also, does this have the same semantics as var()? I.e. IACVT?<br> <emilio> ... also, any example for the "shorthand with bigger value space than longhands"?<br> <emilio> oriol: re the later, -webkit-background-clip: text vs background-clip used to be an issue<br> <emilio> ... re. whole value, yes, can't mix it around<br> <astearns> ack flackr<br> <emilio> ... re. var(), no strong opinion<br> <emilio> flackr: does this need to be writing-mode aware? e.g. if you try to set a logical value from a longhand or so?<br> <emilio> oriol: currently the margin longhands only expands to the physical ones<br> <emilio> ... so it kind of avoids this problem<br> <emilio> ... don't want to introduce lots of complexity with this<br> <emilio> ... in the issue kbabbitt was asking whether from-shorthand() should track exactly the value that was set to the shorthand even if parts of it are irrelevant. I'm fine not tracking the value exactly<br> <emilio> ... whatever is easier is fine with me<br> <emilio> q+<br> <emilio> ... not trying to make things very complex<br> <emilio> flackr: let me give a specific example<br> <emilio> ... if you try to set `margin-top: from-shorthand(margin-block: ...)`, is that invalid?<br> <emilio> oriol: it would be cause `margin-top` is not a longhand of `margin-block`<br> <emilio> flackr: thanks I think that answers my question, so it'd be syntactically invalid<br> <astearns> ack dbaron<br> <emilio> dbaron: generally supportive of this, a bunch of details that need to be taken care of, gonna ask about them<br> <emilio> ... some of them need to happen at specified-value time<br> <emilio> ... i.e. when you look at the specified value to margin-left the only way to represent that is using this thing<br> <emilio> ... so we have to generate it at specified-value time in a bunch of cases<br> <emilio> ... one comment is that we need to be very clear about what those cases are<br> <emilio> ... we've had this happen in other cases like the initial keyword<br> <emilio> ... in which different impls you could generate the initial value even if not strictly necessary<br> <emilio> ... I tend to think we should tend to minimize them<br> <emilio> ... but I feel less strongly about that<br> <emilio> ... also we need to be clear about when this is processed<br> <emilio> ... i.e. do we need this two phase thing where we could process some at specified value time, and others at computed-value time<br> <emilio> ... I _think_ we should deal with this as specified-value time<br> <emilio> ... when possible<br> <emilio> ... but also not feeling super-strongly<br> <emilio> oriol: Re. the first we should probably restrict it to the cases where browsers right now have to serialize to the empty string<br> <emilio> ... re. the second I don't feel strongly either way<br> <emilio> astearns: I don't think merely specifying that you use this new thing where we are serializing to empty string is likely to be sufficient<br> <emilio> ... there might be different cases where browsers do different things<br> <emilio> ... and specify exactly what happens<br> <emilio> ... so that we can get those corner cases down<br> <emilio> ... the other things that in this discussion is that I think this always goes away at specified-value time<br> <emilio> dbaron: yeah it does always go away at computed-value time<br> <astearns> s/specified-value time/computed-value time/<br> <emilio> ... but when you write something like `margin-left: from-shorthand(margin: 1px)` we could simplify to 1px<br> <emilio> astearns: the other thing is author using it not as intended<br> <emilio> ... I think people could misuse it<br> <astearns> q?<br> <astearns> ack astearns<br> <emilio> ... though I like the round-tripping<br> <emilio> oriol: in some cases it could stay in the computed value, so re. background-clip: text it should serialize in the computed value<br> <emilio> ... re the second one if it's useful why not, even if it's a bit hacky<br> <emilio> astearns: I don't have any specific ideas off hand<br> <astearns> ack emilio<br> <emilio> ... just thinking we should not add something that we didn't intend<br> <fantasai> scribe+<br> <fantasai> emilio: I don't think we should take `background-clip: text` as a precedent. Assume it goes away at specified value time.<br> <fantasai> emilio: The fact that it wasn't representable in `background-clip` was an obvious mistake.<br> <fantasai> emilio: The other thing, at least in Gecko, when this happens as a result of variables, you need to avoid reparsing the shorthand over and over<br> <fantasai> emilio: They all get processed at variable substitution time.<br> <fantasai> emilio: I think it's less of a concern for the cases dbaron was mentioning.<br> <fantasai> emilio: For simplicity's sake, if trying to keep this minimal, ...<br> <fantasai> emilio: Taking to extreme, restrict only cases where there are variables inside, so only existing unparsed values.<br> <fantasai> emilio: I would lean towards processing this at the same stage<br> <fantasai> emilio: I cannot think of many use cases for doing this intentionally as an author, other than variable substitution.<br> <astearns> ack fantasai<br> <emilio> scribe+<br> <emilio> fantasai: q from our team is what real world problems does this solve?<br> <emilio> ... are people actually running into this problem<br> <emilio> astearns: there are bugs filed on this on browsers<br> <emilio> oriol: yeah andruud's issue came from a crbug from a developer<br> <emilio> ... so probably not the most frequent issue, but annoying for authors<br> <lea> I'd argue that any use case involving CSSStyleDeclaration is affected by this<br> <emilio> fantasai: will take that back to the team, thanks<br> <emilio> astearns: should we resolve on working on this?<br> <emilio> +1<br> <emilio> PROPOSED: Start drafting a solution in css-values-5<br> <emilio> RESOLVED: Start drafting a solution in css-values-5<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8055#issuecomment-3922160046 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 February 2026 17:28:52 UTC