- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Feb 2024 22:24:31 +0000
- To: public-css-archive@w3.org
> It's pretty difficult to keep track of that. Maybe habit would make it easier, but I'm not sure. I'm not sure what you're finding confusing here. Inside the mixin, you have access to precisely the variables listed in your arglist (or your using() list), and nothing more. There is no reason to care at all how the user of your mixin is spelling what they're passing in. Could you elaborate a bit more on what exactly the problem you're having is? > [using $ inside of mixins/functions] I'd forgotten about that! Yeah, that's actually pretty legit I think. Since the current plan is for the args to have default values declared in the arglist, you don't need that functionality at the usage site anymore. Potential issues, tho: * the `using()` list is still referring to variables from the outside. Do we want to keep using `var()` syntax for those? (I think yes; you can alternately declare a `$foo: var(--foo)` variable in the arglist to make it default to pulling in the value of that variable when the arg isn't passed.) * We want the ability to declare "local variables" - currently by just treating the function definition like it's a declaration list that only accepts custom properties. How would that interact here? `--foo: 1` be referenced as `$foo`? or as `$--foo`? Or should they be declared as `$foo: 1` instead? If we go with `$foo: 1` for local variables, that does fix a problem in mixins, where we probably want to be able to distinguish between "local variable declared for use inside the mixin only" and "custom property being set by the mixin for usage elsewhere". If the mixin used `$foo: 1` it would be a local variable, if it used `--foo: 2;` it would be an exported custom property (but also be usable from within the mixin as `var(--foo)`, as usual). -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9350#issuecomment-1939709422 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 February 2024 22:24:34 UTC