@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.

@JaneOri The *secondary* benefit of it is predictability. When you write `--my-func(1, var(--arg), 3)`, you very likely expect the arg to set the second argument. But in the earlier pre-spread version, it `--arg` contains commas, it would set *multiple* arguments. You could defensively wrap it like `--my-func(1, {var(--arg)}, 3)`, but we don't expect people to remember to do that.

The new spread behavior makes it work as we think people will expect, by default.

@JaneOri Purely as an author-expectation language design issue, I think there's reasonable arguments both ways.

I came down in favor of the behavior split so we *could* do short-circuiting. There's a more ideal CSS where this is more consistent across the board, but we work with what we've got.

@tabatkins Does that mean the short circuiting doesn't/can't happen when you pass var into the arguments of a standard function call?

My density in grasping it is not understanding clearly why it's different for standard functions - or why custom function calls aren't "wired" in the same way.

I appreciate you sharing this depth of information, it's in the weeds but clarity of /why/ makes it much easier to communicate and lean on downstream - in demos, libraries, articles, docs, and hacks.

Ty!