- From: Miriam Suzanne via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Sep 2023 15:24:33 +0000
- To: public-css-archive@w3.org
> I presume that anything without a default value would be a required arg, making the function invalid if not passed? I would not presume that, since _guaranteed invalid_ is a reasonable default value. Is there a strong reason that should need to be specified explicitly in an `@parameter` rule? > think it's probably pretty important to allow functions to access the variables present on the element. I'm open to this. As mentioned above, my stronger concern is that changes to an external variable don't accidentally escape the function. > > 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? That comment was not about a special syntax for functions, but a normal syntax _allowed inside functions_. The only potential need for a special syntax would be if we want to allow some (restricted) parameters in function at-rules. But this proposal does not include that as an initial requirement. (It's also not specific to the `@return` syntax, but should work no matter how the returned value is declared). -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9350#issuecomment-1719669729 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 15:24:35 UTC