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

First, I've talked this over with Miriam already, and broadly am happy with the elaboration on my earlier idea of making functions basically just "fancy variables".

------

Edited before posting: whoops, yeah, the edited version of argument syntax makes me a *lot* happier. I think we can still put syntax into the arglist, fwiw.

```css
@function --foo (--bar "<string>", --baz "<number>") {...}
```

I think that still reads reasonably? And if it is too long and hard to read, you can always move it to `@parameter`s.

(I presume that anything without a default value would be a required arg, making the function invalid if not passed? Since args in the arglist wouldn't have a default, that would match up with the usual practice of required args coming first, followed by optional args.)

--------

> To avoid accidental conflicts, internal function logic would not have access to external custom properties besides the values explicitly passed in to the defined parameters.

I disagree with this, and think it's probably pretty important to allow functions to access the variables present on the element. I don't see any way for there to be an accidental conflict; every name that could potentially conflict is function-local and controlled by the function author, no?

Tho, hm, we'd have to be a little careful about nested functions. If we did make ambient variables available we'd have to decide whether all functions saw the element's vars, or saw the function's vars too. The latter *does* have an accidental shadowing concern.

But I feel like it's important to allow this, because otherwise you can't replace existing variables (that reference other vars) with functions unless you explicitly pass those variables, which can be annoying. In *particular*, it means you couldn't use custom units unless they were explicitly passed to the function, which feels extra-obnoxious.

> However, it would be useful for functions to have internally-scoped custom properties.

Yes, this sounds great. Temp vars are useful.

> Internally, both syntaxes should allow conditional at-rules such as `@media`, `@container`, and `@supports`. That's one of the primary functions that CSS-based functions and mixins could provide. 

I agree that these are useful, but their usefulness isn't specific to functions. We've talked about a `media()` function that lets you do MQ-specific value resolution; should we just rely on that rather than having a special syntax just for functions?

(I'm not particularly *against* doing the `@return` and allowing conditional rules, fwiw. Just wondering if it would be better to lean on the generic functionality.)

-------

Unmentioned here is what to do about recursive functions. Without the ability to test and branch on the value of one of the input variables, I think a recursive call is guaranteed to be cyclic just like a custom-property self-reference is, right? So presumably that should be detected and auto-failed using the existing anti-cyclic variable tech. If we later allow for the possibility of useful recursion we can relax the requirement and impose a stack limit or something. (Then we can repeat the TC39 arguments about tail recursion, yay!)

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


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

Received on Thursday, 14 September 2023 14:48:04 UTC