Re: [css-houdini-drafts] Proposal: Custom functions for modifying CSS values (#857)

Overall, this looks very close to what I'd put together; great job!

> Alternatively, we could stick with the Paint API model: each registered function could be required to have its own class (which maybe extends a superclass that defines the input and return type getters), and the calculations would always use a function with a standard name (calculate, value, or something like that).

Yeah, separate class is my plan. Anything else is just adding complexity to the model without much gain, since one can just inherit from a base class, as you say.

> An alternative would be to register the custom function as a regular ident (no -- at the beginning), and then have a single standard wrapper function where the specific function name is the first argument to the wrapper, similar to how paint() works:

I favor defining a -- name directly; I think it looks better and is clear enough. paint(), being specialized for 'display', is well-suited to having a single function name with the author-specified ident being an argument; custom functions, being usable *anywhere*, are well-suited for their author-chosen names being top-level.

> At what level should input argument types and return types be enforced. If they aren't enforced by the parser, what is the fallback behavior?

Enforcing at parser level would be *ideal*, but it means we have to reparse the stylesheet when a function is registered. We purposely chose not to do that for registered custom properties, so I suspect we'll want to be consistent with that.

In other words, a custom function will be, for most purposes, exactly equivalent to a `var()` function; any property using one will be assumed to be valid at parse time, and flip into "invalid at computed-value time" if something is wrong - either a bad return type, or the JS throws, or whatever.

It would be best if we could avoid this, but we'd have to make an explicit decision to go against our previous precedent. I'll def try.

> How does this interact with computed values and inheritance?

Same as var() with a registered custom property, basically: filled in as part of the computed-value process.

> Could this not use functions and named parameters instead to registerCustomFunction?

This is a really interesting idea; coming up with a named-parameter syntax and exposing that to the JS as an options bag could skip around a lot of the issues with the more limited syntax rules that custom functions are allowed.

-------

There's a bit more detail specific to functions that we want to expose, which are needed for a good `--random()` function; you need the ability to specify whether you'll get re-called based on being applied to different properties/elements, in addition to different arguments.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/857#issuecomment-487167753 using your GitHub account

Received on Friday, 26 April 2019 19:10:00 UTC