- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Jul 2022 16:01:45 +0000
- To: public-css-archive@w3.org
> One issue that might (but I'm not sure) be difficult (although maybe more for designing/specifying the feature than for implementing it) is determining when the functions are resolved. (Does it work like calc() and depend on what the arguments are?) It would just be variable substitution, nothing more, nothing less. (Well, *something* more - we validate the arguments per the syntax as a help to the author, identical to registered properties. So still "just" variable substitution.) The fact that the OP example is a math function has nothing to do with the custom function part, it just means that when it var-substitutes you get left with a math function, same as `--foo: clamp(...); width: var(--foo);`. This is just var substitution with some "time-of-use" subs (the arguments) rather than "time of definition" subs (what you'd get today if you tried to do something similar with custom properties). > [stuff about arg()] My suggested syntax just used var() and normal custom property names for simplicity, and to underscore the fact that this is just var substitution under the covers. It also means you get the same var() behaviors you'd get elsewhere, like the ability to specify fallback values (useful if the argument doesn't match its declared syntax, as it'll sub the guaranteed-invalid value otherwise, per standard variable rules). That said, it's possible we may want to do smarter stuff for the arguments, in which case it would make sense to have a different function. I just can't come up with any "smarter stuff" yet. > (That is, whether the result could use [initial, inherit, etc].) That's the nice thing about making it just a slightly special case of variable substitution - we've already got answers to those questions. ^_^ > Somewhat related, maybe? depending on how you squint at it? https://github.com/w3c/css-houdini-drafts/issues/857 Definitely related. This would be a simple declarative version of the more full-featured, JS-driven Houdini feature linked there. I imagine they'd live in the same namespace and registered Houdini functions override @function declarations of the same name. They should already have similar behavior in many respects; that is, the Houdini feature will also be *essentially* just variable substitution, but with JS providing the substitution value. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7490#issuecomment-1183405150 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 July 2022 16:01:47 UTC