@JaneOri Spread operator is already defined in the spec!

https://drafts.csswg.org/css-values-5/#early-resolution

@tabatkins I'm grateful the spread operator will open this potential but I keep coming back to feeling the inconsistentcy that csv vars spread in standard function calls but not in custom function calls

It *feels* wrong/broken from this side of using CSS since the expectation is already set. As the/a spec author do you feel any way about the discrepancy? Seemed like Anders solved it to spread before the discussion decision to ship no-spread; Without knowing why, I'm left curious

@tabatkins interesting... The speed benefit of not automatically spreading makes sense on the surface, but doesn't standard function auto-spread require the same evaluation?

If no, it's unexpected that the conditional tree needs to resolve what parameters might-be-set ahead of time only for custom functions. My assumption would be resolve the parameters, call the function, but it sounds like it's more interwoven like a pre compiled in-place substitution is happening?

@JaneOri The short-circuiting isn't really a speed benefit (tho it does accomplish that a little); instead, it prevents later *unused* variables from creating reference cycles that'll affect earlier variables.

Note as well that this isn't just custom functions, it's *all* "arbitrary substitution functions" - var(), if(), attr(), etc. Anything that can emit an *arbitrary* token sequence in any location has this spread behavior, now.