Re: [csswg-drafts] Proposal: Custom CSS Functions & Mixins (#9350)

> I'm not sure if I like the need for explicitly defining the variables that are used from the outer scope. What are the issues does this solve?

I gave two reasons for it:

> the strong convention of nearly every programming language in the world suggests that going completely lexical is ideal - the only names visible to the function body are listed in its arg list.
> [...]
> This also puts us in a good spot for future expansion into JS-backed custom functions, since JS is strictly lexical as well. 

------

> from which scope does it use the variables? From the outermost, closest, or only the immediately above one?

The scope it's called in.  In your example, `--foo()` will see an undefined `--var1` (aka the guaranteed-invalid value) and a `--var2` of 10.

> The requirement to explicitly mention all the tokens will make these functions difficult to write and maintain.

If we had to explicitly pass all of them as variables, I'd definitely agree. As written, tho, you just have to state them once per function definition.

Also, design tokens are generally going to be global, which means that as we pursue the [custom env() idea](https://github.com/w3c/csswg-drafts/issues/9206), you can switch to using those instead. They won't need to be passed in; like other programming languages, global variables will be globally available. (And unlike other programming languages, they're immutable, so it's actually safe to use them.)

--------

> I like the CSS-ness of the logic behind this, however, having the last return win seems unexpected from what I'm used to with other languages where the first return wins and stop further code execution.

Right, but it's *not* executing imperatively, in this idea. It's just a bag of properties, acting like bags of properties always do.  For example, in the following:

```css
@function --foo(--arg1: 1) {
  --arg2: calc(var(--arg1) + 1);
  --arg1: 10;
  return: calc(var(--arg1) * var(--arg2));
}
```
calling `--foo()` would return 110, not 20, because `--arg1`  is set to 10 in the property list, and `--arg2` depends on it, per normal variable dependency rules, so it sees the value 10.  Again, this is identical to just inlining these custom props into a style rule.

> I'm thinking that conditions would eventually make their way into functions,

Yes, [we've got plans for conditionals in normal CSS](https://github.com/w3c/csswg-drafts/issues/5009#issuecomment-626072319), which will work in the declarative model too:

```css
@function --foo(--arg1: 1) {
  return: cond(
    (var(--arg1) < 0) 0,
    calc(2 + sin(var(--arg1)))
  );
}
```

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 9 February 2024 19:08:04 UTC