- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Apr 2026 21:53:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-mixins-1] Using a scoping rule breaks author expectations, can we get rid of it?`, and agreed to the following:
* `RESOLVED: Drop @scope'ing from @mixin. Values that can't resolve because they're outside the subtree are guaranteed-invalid.`
* `SUMMARY: Look into some ideas around merging @mixin and @macro.`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> slides at https://webplatform.design/talks/mixins/<br>
<fantasai> Lea: Review of the current state of mixins!<br>
<fantasai> lea: This example uses a sibling selector. But that rule gets ignored because we implicitly wrap everything in @scope.<br>
<fantasai> lea: Is @scope inherently confusing? No. But implicitly using it for mixins is.<br>
<fantasai> lea: You might not want that scoping.<br>
<fantasai> lea: So then we defined @macro which doesn't do the scoping.<br>
<fantasai> lea: But it's very limited, like no arguments.<br>
<fantasai> lea: So I made a poll on social media. I gave ppl a chunk of code with various style rules in a mixin.<br>
<fantasai> lea: What's your expected result?<br>
<fantasai> lea: Here's the results. With 100+ votes.<br>
<fantasai> lea: Caveat -- this mixin has a typed argument. But didn't highlight that point, so can't really distinguish A vs B or C vs D<br>
<fantasai> lea: But if you join A+B and C+D, you get a very strong signal: 90%+<br>
<fantasai> lea: No expectation that the sibling selector rule would get ignored.<br>
<fantasai> lea: People were *baffled* why it wouldn't work.<br>
<fantasai> lea: Why did we define mixins with @scope? There was a good reason.<br>
<fantasai> ...This example styles the element, ancestor, and sibling.<br>
<fantasai> ... [stuff]<br>
<fantasai> ... Within the non-negotiable constraint that we can't depend on the computed value of elements outside a subtree.<br>
<fantasai> ... Current spec takes nuclear option of using @scope, which ignores outside the scope<br>
<fantasai> ... even if it doesn't have a dependency on this info.<br>
<fantasai> lea: Ignoring the rule is definitey not author intent!<br>
<fantasai> ... the main non-negotiable is that element-relative values must have the same value thorughout the mixin. but if we relax it, and make it *throughout the applying element's subtree*, then we can have more flexibility.<br>
<fantasai> lea: Some options<br>
<fantasai> ... could be guaranteed invalid<br>
<fantasai> ... or resolve per-element and then inherit down<br>
<fantasai> ... or something else.<br>
<fantasai> ... it's not an implementation restriction, it's question of what we want to do<br>
<fantasai> ... 1 is the most straightforward, and authors can provde fallbacks<br>
<fantasai> ... 2-3 might capture intent better, but weirder, might need more author research<br>
<fantasai> ... and then question of typed vs untyped arguments<br>
<astearns> q?<br>
<fantasai> lea: Another option is to rename @macro to @mixin and @mixin to @scoped-mixin or something else that makes the scoping very obvious.<br>
<fantasai> ... Still need arguments for @macro to be usable<br>
<fantasai> ... Maybe use syntactic substitution, like a preprocessor.<br>
<fantasai> ... But then inheritance is a question.<br>
<fantasai> lea: Main questions are<br>
<fantasai> ... 1. Should we do better than dropping the entire rule?<br>
<fantasai> ... 2. Should we tyr to resolve locals, or is guaranteed-invalid ok?<br>
<kizu> q+<br>
<fantasai> ... 3. What do we resolve them to?<br>
<astearns> ack kizu<br>
<fantasai> kizu: I think I agree with everything Lea mentioned.<br>
<fantasai> ... First, yes, we need to do something. Fully dropping rules from author perspective will feel weird.<br>
<fantasai> ... How to resolve locals, good question.<br>
<fantasai> ... If we have a scoped version, should be explicit in the syntax.<br>
<fantasai> TabAtkins: [projects a diagram]<br>
<fantasai> root -> @apply -> [ child --prop "6", child font-size:30px ]<br>
<fantasai> @mixin<br>
<fantasai> TabAtkins: First question is, if we look into mixin, we have one usage of arg1 and one usage of arg2. Feels like they should behave the same.<br>
<fantasai> TabAtkins: These are resolved to some value, and usage inside hte function body is the same.<br>
<fantasai> TabAtkins: We achieve that in the spec by rewriting arg1 and arg2 into magical custom properties on the element.<br>
<fantasai> TabAtkins: that let's us resolve arg1 into a 10em length, becoming 100px<br>
<fantasai> TabAtkins: and then those inherit normally.<br>
<fantasai> TabAtkins: Children and ::before will all have consistency<br>
<fantasai> TabAtkins: That's implemented via custom properties and inheritane.<br>
<fantasai> TabAtkins: Complexity is if you bring in more elements and then extend mixin to also style the sibling and the nibling.<br>
<fantasai> TabAtkins: What happens here? Assumptions that all usages inside our mixin apply here<br>
<fantasai> TabAtkins: but there's no way to reference the size of an 'em' or the value of a custom property on siblings or cousins.<br>
<lea> q?<br>
<lea> q+<br>
<fantasai> TabAtkins: if we want arguments to be able to resolve, for basic circularity reasons, they have to get scoped<br>
<fantasai> TabAtkins: Lea's proposal is that arg1 and arg2 don't always resolve to the same value.<br>
<fantasai> TabAtkins: if they apply to something ouside the tree, they 'll resolve to something else. Possibly invalid.<br>
<fantasai> TabAtkins: I don't like that happening. Fact that a var resolves to a predictable stable value, but used other places depending on where in the tree, is an odd behavior.<br>
<fantasai> TabAtkins: It's also weird if you're not using vars at all you can't ge tit<br>
<fantasai> TabAtkins: because rules are scoped<br>
<fantasai> TabAtkins: I don't want to have it where you can use rules outside the scope as long as they're not using a variable reference<br>
<fantasai> TabAtkins: seems like a complicated boundary for authors to learn about<br>
<fantasai> TabAtkins: scoping is not obvious. But you can learn it.<br>
<fantasai> TabAtkins: Now we also have @macro so you can use that.<br>
<fantasai> TabAtkins: Example<br>
<fantasai> @macro --foo(--arg) {<br>
<fantasai> &, & > *, & + * { width: var(--arg); }<br>
<fantasai> }<br>
<fantasai> .foo { @apply --foo(10em); }<br>
<fantasai> This would desugar to a literal substitution of 10em. It would resolve locally on each element it resolves on.<br>
<fantasai> TabAtkins: every usage is the same, they all resolve on the local element.<br>
<kizu> q+<br>
<florian> q+<br>
<fantasai> TabAtkins: Pass in a variable, same thing. It resolves locally on each element.<br>
<miriam> q+<br>
<fantasai> TabAtkins: My preference would be to have @macro do the literal writing. And predictable. Can achieve some of the use cases by haivng intermediary variable.<br>
<fantasai> --test: --as-length(var(--prop));<br>
<fantasai> &, &>*,&+* { width: var(--test); }<br>
<fantasai> TabAtkins: If others lean towards Lea's position, then the only case that I think makes sense is making things invalid.<br>
<fantasai> TabAtkins: If we need to have unscoped rules in the mixin, then that's the only thing that seems ok.<br>
<astearns> ack lea<br>
<fantasai> lea: I think what you presented is good for @macro anyway. It does need more research if syntactic rewriting covers all use cases. What happens with transitions/animations if no real property, for example?<br>
<fantasai> lea: But the reason I hear for @scope inside @mixin is because we don't like what authors are doing.<br>
<fantasai> lea: It's not actually necessary though.<br>
<fantasai> lea: And no way for them to escape the @scope rule.<br>
<fantasai> lea: They can always include one if they want it, if we don't force it.<br>
<fantasai> lea: Nothing would change inside the scope either way, only unscoped rules behavior would change.<br>
<fantasai> lea: Mental model of mixin is to avoid name clashes, and defined on applying element, and what happens with regular properties happens.<br>
<fantasai> lea: Yes, authors can learn and live with it as they have for many other things that are confusing in CSS.<br>
<fantasai> ... just because authors can use learn it doens't mean we should burden them with learning<br>
<fantasai> lea: Wrt macro arguments, what's the point of typing?<br>
<astearns> ack fantasai<br>
<TabAtkins> scribe+<br>
<TabAtkins> fantasai: my impression si that what makes the most sense is to not scope the contents of the Mixin block<br>
<TabAtkins> fantasai: that affects specificity, it cuts out the out of scope rules. several effects<br>
<TabAtkins> fantasai: I agree with Tab where if there's no reasoanble way to resolve the variables, it's the GIV<br>
<TabAtkins> fantasai: so I think you'd not scope them...<br>
<florian> q?<br>
<fantasai> fantasai: and use the guaranteed-invalid value if it's dereferenced on an element that cna't resove it<br>
<astearns> ack kizu<br>
<fantasai> kizu: I'm not sure we need typed arguments for macros.<br>
<fantasai> kizu: Maybe there's a value for mixins, but it can create confusion.<br>
<lea> I would def support L1 to only have untyped arguments<br>
<fantasai> kizu: I think from author perspective, invalid at computed value time is reasonable, and learnable<br>
<fantasai> kizu: If we could have an ident function and you wanted to resolve it inside the mixin and not where you code, we could maybe do that<br>
<fantasai> kizu: [gives an example]<br>
<fantasai> kizu: If we do that, what's the difference between macros and non-macros.<br>
<astearns> ack florian<br>
<fantasai> florian: Thing Tab presented as macros will be intuitive to people, acts like a preprocessor.<br>
<fantasai> florian: The behavior of mixins is arguably more useful. But not obvious from its name that it's what it does.<br>
<fantasai> florian: So maybe naming can help?<br>
<fantasai> florian: They're basically resolved macros. Resolve it on an element, and then apply from there.<br>
<fantasai> florian: Then whether it's the scoping that makes it clear, in order to resolve you need to scope to a tree, or the other option that you like less, yes you can have rules outside but values there will be invalid<br>
<fantasai> florian: that's also understandable. If you resolve to a subtree, and try to use outside subtree, of course you can't get it.<br>
<fantasai> florian: I'm probably leaning towards param values are invalid, but the rules still are there.<br>
<lea> q+<br>
<fantasai> florian: but finding a helpful name to hint people why they are different ...<br>
<astearns> ack miriam<br>
<fantasai> miriam: I'm agreeing with most others, esp florian<br>
<fantasai> miriam: It seems the more powerful we make macros, they do just about everything I want from a mixin<br>
<fantasai> miriam: Idk that resolving on the called element is that important that it determines what a mixin can do<br>
<fantasai> miriam: So I would support basic and flexible mixin, and then have a more powerful variant of mixins if we need it<br>
<astearns> ack lea<br>
<florian> q+<br>
<fantasai> lea: I do think one of the two should be named @mixin.<br>
<fantasai> lea: Like, people are still asking for parent selector , because we never made one even though we have the functionality.<br>
<fantasai> lea: I don't care much about the scoped one, probaby wouldn't use it much<br>
<astearns> ack florian<br>
<fantasai> florian: What if, given the difference is about resolving, we make the resolving explicit?<br>
<fantasai> florian: Like in your mixin macro, you say what element it resolves on, it resolves it<br>
<fantasai> florian: you could resolve on parent or whatever<br>
<fantasai> florian: and if you don't resolve you get macro behavior<br>
<miriam> (resolve on named container?)<br>
<fantasai> florian: and because you explicitly do this, it's less magical<br>
<fantasai> +1 to the idea but needs more concreteness :)<br>
<fantasai> florian: An maybe have some shortcuts for the common cases<br>
<fantasai> miriam: A named container would be guaranteed parent of everything<br>
<ntim> what issue are we talking about<br>
<fantasai> TabAtkins: proposal that if you reference mixin argument or local from an element that can't see the applying element, that resolves to guaranteed-invalid value<br>
<fantasai> TabAtkins: so not scoped like @scope<br>
<lea> +1<br>
<fantasai> PROPOSED: Drop @scope'ing from @mixin. Values that can't resolve because they're outside the subtree are guaranteed-invalid.<br>
<ntim> q+<br>
<fantasai> RESOLVED: Drop @scope'ing from @mixin. Values that can't resolve because they're outside the subtree are guaranteed-invalid.<br>
<lea> PROPOSED: `@macro` (or whatever it’s called) should get (untyped) arguments<br>
<fantasai> fantasai: Seems like there was an interest in possibly merging and macros, which has a lot of options to think through.<br>
<fantasai> SUMMARY: Look into some ideas around merging @mixin and @macro.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13727#issuecomment-4173187508 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 April 2026 21:53:29 UTC