- From: Tab Atkins Jr. via GitHub <noreply@w3.org>
- Date: Wed, 16 Jul 2025 18:37:46 +0000
- To: public-css-archive@w3.org
> What's the purpose of declaring @contents in the @mixin prelude? Just as a signal in the definition that it *intends* to take contents. Could be skipped, but I think it's useful to demark that, so that mistaken attempts to pass a block to a mixin that doesn't use them get correctly flagged as an error. It's also similar to the behavior where passing *too many* arguments causes the invocation (both for functions and mixins) to fail. > Maybe worth an example? Edits welcome. ^_^ (Please, feel free to provide or tweak *any* of the examples you think could use improving. No need to run them by me.) > I'm less sure about applying unused apply-side contents as nested rules. If the mixin doesn't use the contents, I think we might want to ignore those declarations. Not sure what you mean by this. Where are you seeing text that suggests something like this? > Example 18 doesn't show an em parameter being passed to the mixin. Lol, I guess after I wrote the `em` in the contents block my brain figured it was finished. Fixed, thanks. (For those following at home, that's now example 20, in <https://drafts.csswg.org/css-mixins/#dependent-envs>.) > It might be helpful to have more explicit examples for how custom properties and environment variables / mixin parameters can or can't be used together. Definitely. I'll try to add some more, but if you feel inspired, feel free to as well. > But I do wonder if we want a built-in way to explicitly resolve values. Authors clearly want access to that functionality, and there's no reason to make every project re-invent the --to-length() function. Definitely agreed. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9350#issuecomment-3079833575 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 16 July 2025 18:37:47 UTC