- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Sep 2023 07:52:28 +0000
- To: public-css-archive@w3.org
>> Mixins return [...] rule blocks (including selectors and other at-rules) >> >> [...] mixins [...] would be resolved during variable substitution > > Those two things are not compatible. But it's possible that we'll able to impose enough restrictions on this to make it feasible, and still get something useful. For example, limit mixins to only declarations, or only declarations and nested &-rules (which would allow your nested @supports example). Right, I assumed that they'd be applied before any value stages, essentially equivalent to doing a preprocessor. As far as I can tell there's nothing dynamic about mixins (save the values passed in themselves, but they're effectively just uniquely-named variables). (And note that we already established, back in the last attempt at `@apply`, that passing around declaration blocks via computed values is not viable.) That, I think, would allow us a lot of freedom in what to allow inside the mixin without adding a lot of complexity. However, it limits our ability (somewhat) to do branching/etc based on the values. We could still do, say, a `@for` based on a *static* value (like `@apply --foo(5)`), but not on a dynamic one (like `@apply --foo(var(--bar))` or `@apply --foo(counter(list-item))`. But that's something to worry about in the future; we're not doing conditionals or loops yet. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9350#issuecomment-1720836487 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 September 2023 07:52:30 UTC