@kizu even if you assigned it to a registered property? I'd imagine/expect the computed style would resolve at that moment... Unless it's already considered a color syntactically I suppose...

@kizu I also could use this right now so I don't have to split focus and do it for myself lol

@tabatkins Every edge case and caveat adds to comprehension debt and must be forwarded to end users of a CSS --library().
*I* don't mind the nuance, but I really don't want my users to have to consider any of it when calling my function

@tabatkins It's entirely possible you are right but I may need to provide a real world example for you beyond our post limits here to demonstrate how much extra documentation caveats it causes... We have to set expectations for CSS users in our --custom() library who may be using custom functions for the first time, every tiny difference between standard vs custom vs raw vs var arguments. Auto spread is a single detail w/no further scenario discrimination: CSS vars always spread, wrap the arg {}

@tabatkins all that to say was simply to make the point that it's not too late to change back because it's not going to be used currently

@tabatkins so the point wasn't that it won't be useful, but that it's currently not useful as implemented AND it's causing downstream DX nightmares as-is - auto spread eliminates the vast majority of caveats. Also... it makes more sense in CSS because it's currently doing something weird - for the very first time, using var() somewhere is not expanding in place, but instead expanding later, after the custom function argument... Your initial {} concept was completely rational in CSS programming

@tabatkins you have spec'd out several things that make single argument list digestible (spread, nth-item, etc) which will be awesome once implemented somewhere... but currently using the entire list as-is to... stitch together a font property? You don't need a custom function to do that, just using var()s does that...
There isn't a use case currently that makes csv arguments useful (without your other work implemented).
Auto spread eliminates most of the caveats to explain in docs/preferred DX

@tabatkins the last minute remark was reading timestamps of when Anders had it detailed and working to 11 minutes later when it was decided not to:
https://issues.chromium.org/issues/390205875#comment4
The short circuiting cycle prevention happens before they spread as arguments to a standard function call like hsl() so I still don't grok the distinction that it can't happen in custom --hsl()