[csswg-drafts] [css-functions-mixins] spreading comma separated var values into multiple arguments by default when calling a custom function (#13927)

JaneOri has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-functions-mixins] spreading comma separated var values into multiple arguments by default when calling a custom function ==
_Creating this issue as requested on mastodon._

Calling a custom function is only place in CSS where the expected/established DX of vars effectively spreading in-place doesn't happen.

```css
--rgb: 255, 0, 0;
color: rgb(var(--rgb));
```

As a CSS author, this anti-spreading behavior feels broken/unexpected.
(and is incredibly disappointing to not have access to the enormous potential of argument spreading)

It was originally planned and assumed as the rational expectation:
https://github.com/w3c/csswg-drafts/issues/11190#issuecomment-2596276757

It appears that it was implemented:
https://issues.chromium.org/issues/390205875#comment3

and then cancelled shortly after (afaik, without public discussion):
https://issues.chromium.org/issues/390205875#comment5

The `{var(--csv)}` syntax to prevent spreading makes sense from the perspective of a CSS author and is implemented / shipped.

---

The primary counter argument caters to non-CSS developers, stating that other languages don't auto spread arguments so CSS custom functions shouldn't either.

I whole heartedly disagree with the conclusion of this counter argument but so far I have stood alone in intention to question it.

Other counter arguments I've seen are situational and don't uniformly apply (like when arguments are typed, the evaluation happens anyway, etc).

---

For context, I have written dozens of complex custom functions, including working, trivial DX, --repeat() and --loop() functions, an entire bitwise suite, and am actively writing many more.

I know questioning decisions already made is not a pleasant thing to do so I apologize for that while still being incredibly hopeful that the expectation will be restored.


---

It also seems like it would be difficult to maintain erroring when too many arguments are used in the call... though I also want to say that it is confusing DX to try debugging why a function isn't working at all. (Is something cyclic? A semicolon missing? Comma missing? Something else?) Without a CSS error console, it is much much easier to debug an incorrect argument causing weird behavior than to experience when a function isn't returning anything at all.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13927 using your GitHub account


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

Received on Thursday, 14 May 2026 21:12:47 UTC