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

> Hm, if we go with "it's just a declaration list, that only accepts custom properties", maybe it would be more sensible then to make the return value a (non-dashed) property as well:
> 
> ```css
> @function --foo(--arg1: 1) {
>   --arg2: sin(var(--arg1));
>   --arg1: 2;
>   return: calc(var(--arg1) + var(--arg2));
> }
> ```
> 
> The syntax is straightforward, then, and it automatically suggests how it works to have multiple instances of it - the last valid one wins. And if you've provided a return type, we can parse that value and properly reject unknown things, so you can use CSS's normal fallback rules to use new features when they exist and fall back to older stuff otherwise.

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.

I'm thinking that conditions would eventually make their way into functions, so it would be nice to be able to leverage an early return pattern for more complex functions to avoid large `else` blocks, which is why I'd advocate for an `@return` syntax that would stop executing the function once encountered:

```css
@function --foo(--arg1: 1) {
  @if (var(--arg1) < 0) {
    @return 0; /* The code below gets ignored */
  }

  --arg2: sin(var(--arg1));
  --arg1: 2;
  @return calc(var(--arg1) + var(--arg2));
}
```

We could also stop executing at the first `return` without `@` but kinda to your point, that doesn't feel as CSS-like if it's presented as a standard property.

-- 
GitHub Notification of comment by chriskirknielsen
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9350#issuecomment-1936319461 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 17:35:54 UTC