- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Apr 2026 22:36:19 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-mixins-1] Auto-wrap mixin body in `@result` if omitted?``.
<details><summary>The full IRC log of that discussion</summary>
<fantasai> TabAtkins: Currently mixins, like functions, can have local variables.<br>
<fantasai> TabAtkins: Helps with DRY.<br>
<fantasai> TabAtkins: We need some way to distinguish local variables, which are private to the mixin, vs custom properties in the out put of the mixin.<br>
<lea> q+<br>
<fantasai> s/out put/output/<br>
<astearns> ack ntim<br>
<fantasai> TabAtkins: Current model distinguishes by using the @result {} rule, which is used to wrap all of the output of the mixin.<br>
<fantasai> TabAtkins: Anything outside @result is mixin-internal stuff.<br>
<fantasai> TabAtkins: Chose syntax to match the syntax of @function.<br>
<fantasai> TabAtkins: Question from Lea is, can we avoid writing @result in as many cases as possible.<br>
<fantasai> TabAtkins: My opinion is to not make such a heuristic, and require @result always.<br>
<fantasai> TabAtkins: Otherwise no clear syntactic distinction between locals and custom property outputs.<br>
<fantasai> TabAtkins: And not being able to tell is not great. Should be easy to scan quickly and see what's internal vs external.<br>
<fantasai> TabAtkins: This is harder because mixins can have complex conditional logic and nested rules.<br>
<astearns> ack lea<br>
<fantasai> Lea: I can live with this either way. We can always make things optional later even.<br>
<fantasai> lea: But I think this makes simple mixins very noisy.<br>
<fantasai> lea: Introduces an extra level of nesting<br>
<fantasai> lea: I will point out that all of us, while making mixin examples, forgot the @result. Including Tab himself!<br>
<fantasai> lea: But having @result added later in the rule change behavior of previous declarations is a bit confusing also.<br>
<kizu> `@mixin —foo => {}` lol<br>
<lea> scribe+<br>
<fantasai> lea: I'm not a huge fan of @result overall. Separates computation from usage<br>
<lea> lea: Not a huge fan of `@result` overall, it separates computations from their usage, cannot easily have structure (e.g. set a local on child to a different value unless you jump through hoops)<br>
<kizu> q+<br>
<astearns> ack kizu<br>
<fantasai> kizu: We need some way to have locals.<br>
<fantasai> kizu: I would be ok to have @locals<br>
<fantasai> kizu: So by default everything is public<br>
<miriam> q+<br>
<fantasai> kizu: I agree that it's easy to miss, and hard to understand what's going on, and your custom variables become local variables<br>
<fantasai> kizu: so ...<br>
<lea> q+<br>
<fantasai> kizu: Authors will count mixin as a way to not repeat themselves and re-use their CSS<br>
<fantasai> kizu: For more complex cases, can use @locals<br>
<astearns> ack miriam<br>
<fantasai> miriam: I agree, needing @locals is the special case, not the main case.<br>
<fantasai> miriam: So ideally that's what would get extra syntax -- making something loca.<br>
<astearns> ack lea<br>
<lea> lea: Another advantage of `@locals` is it can be used *outside* of mixins<br>
<fantasai> lea: common in regular CSS to have computations that don't make much sense outside of that rule<br>
<miriam> +1<br>
<kizu> q+<br>
<lea> lea: Can have short form for a single local too<br>
<miriam> (though that's something functions solve as well)<br>
<lea> lea: TBD whether you would need to just declare your locals once with this or whether you would need to use this everywhere you use the local<br>
<fantasai> lea: TBD whether you would need to just declare your locals once with this or whether you would need to use this eveyrwhere you use the local<br>
<kizu> Maybe related: https://github.com/w3c/csswg-drafts/issues/11798 ? So not a `@namespace`, but `@local {}`?<br>
<astearns> ack kizu<br>
<TabAtkins> q+<br>
<fantasai> kizu: Maybe name @local and have some way to expose outside of mixins<br>
<lea> oh and agree with miriam that extra locals are the special case, not the default<br>
<fantasai> kizu: but wrapping in @local would let it be limited to this lexical scope<br>
<fantasai> kizu: and then also use it for this mixin<br>
<fantasai> kizu: The only extra thing, if it is used like this in mixin, means you're not wrapping the rule<br>
<fantasai> kizu: verything inside will be using these local values<br>
<fantasai> kizu: but in mixins, you'll want to define @local with some custom properties inside<br>
<fantasai> kizu: and then have custom properties that use those values outside of @local<br>
<fantasai> kizu: lots to think about if we make this a general feature for lexical scoping<br>
<astearns> ack TabAtkins<br>
<fantasai> TabAtkins: main reason Anders and I are against @locals are that @mixin and @function have very similar structure and usage.<br>
<miriam> q+<br>
<fantasai> TabAtkins: having them differ gratuitously in their syntax, I think will cause more confusion than it helps<br>
<fantasai> TabAtkins: Good to have similar constructs spelled similarly<br>
<fantasai> TabAtkins: @function has local variables and a result property<br>
<fantasai> TabAtkins: @mixin having @result is parllel<br>
<fantasai> TabAtkins: romain has same opinion<br>
<fantasai> TabAtkins: We also discussed with Chris Coyier, he immediately understood what the at-rule was doing<br>
<astearns> ack miriam<br>
<fantasai> TabAtkins: So want to keep it because it means similar things are spelled similarly<br>
<fantasai> miriam: I don't think @result is confusing, just bloated.<br>
<fantasai> miriam: Disagree with premise that @function and @mixin only differn in value space or function<br>
<fantasai> miriam: From author view, whether contents are private or public is another difference<br>
<fantasai> miriam: Custom properties in @function are implementation, in @mixin are part of the output<br>
<lea> q+<br>
<fantasai> miriam: Feels like part of the fundamental difference<br>
<fantasai> TabAtkins: I don't understand<br>
<fantasai> miriam: your goal with writing a mixin is to output properties, so outputing custom properteis is reasonable part of that<br>
<lea> +1 miriam<br>
<fantasai> miriam: but functions, not the goal<br>
<fantasai> miriam: custom properties end up being an internal thing, it's reasonable<br>
<fantasai> miriam: So disagree that mixin custom properties being public is confusing<br>
<kizu> +1 to Miriam — functions are at a value level, and authors won’t expect them to output anything other than the `result:`<br>
<fantasai> TabAtkins: i'm confused why you think top-level --foo: whatever in a ixin should be public<br>
<astearns> I agree with Miriam, too<br>
<fantasai> miriam: A big difference between function and mixin is that mixin has public properties, and a function doesn't.<br>
<fantasai> miriam: therefore I'm not surprised that there's a different spelling. They are different features, aligns with the different purposes of these features.<br>
<fantasai> TabAtkins: So mixin shouldn't have local variables?<br>
<fantasai> miriam: No, just saying that they don't have to be spelled the same.<br>
<fantasai> miriam: If we need to mark them as local when they should be local, that's reasonable.<br>
<fantasai> miriam: I'm disagreeing with you and Anders saying it's confusing to use @local instead of @result<br>
<fantasai> astearns: Agree, I'm not convinced that we need to maintain consistency between functions and mixins here.<br>
<fantasai> miriam: Indeed, I'm arguing against the consistency argument here.<br>
<lea> ergonomics > consistency<br>
<fantasai> TabAtkins: I disagree, consistency is important to language design<br>
<fantasai> lea++<br>
<fantasai> miriam: It's what we did inside functions that doesn't fit the language. Because otherwise this spelling is a custom property. Should behave like other properties. no reason to be suddenly private.<br>
<fantasai> miriam: Functions is where we're giving them special behavior<br>
<lea> it's even a TAG principle (that I introduced when I was in the TAG): https://www.w3.org/TR/design-principles/#consistency<br>
<fantasai> TabAtkins: A local is just a way to spell an argument you can't pass.<br>
<fantasai> TabAtkins: Without locals, using unpassed arugments and defaults is the easy way to spell that<br>
<fantasai> miriam: We used the "custom property" spelling for locals and arugments, where really those are two different features.<br>
<fantasai> miriam: I'm arguing that, for consistency, a custom property in a mixin should be like any other property. No reason to assume it's local.<br>
<fantasai> miriam: if we want different spellings between custom properties and locals, it's the locals that should get a new spelling<br>
<astearns> q?<br>
<fantasai> miriam: Custom properties shouldn't need special syntax to make them be custom properties.<br>
<fantasai> miriam: they already have their own syntax.<br>
<astearns> ack lea<br>
<fantasai> miriam: I don't think the consitency argument plays out the way you're saying<br>
<fantasai> lea: +1 to everything miriam just said<br>
<fantasai> lea: I'm not even convinced the similarity is helpful, they're so different.<br>
<fantasai> lea: But in any case, the purpose of consistency is ergonomics. If ergonomics leans towards less consistency, then that's the right anwer.<br>
<fantasai> lea: My understanding is that you can set locals outside @result if you declare them outside @result?<br>
<fantasai> TabAtkins: nope<br>
<fantasai> TabAtkins: Locals exist within the context of an executing mixin<br>
<fantasai> lea: [missed]<br>
<fantasai> lea: Argument about Chris Coyier ... he also thought that the first result property wins, so might be a mental model disconnect there<br>
<astearns> s/[missed]/we re-used custom properties for locals and threw away some of their behavior<br>
<fantasai> lea: But also authors will be biased towards supporting the current design because they want the thing<br>
<fantasai> lea: That's why you don't give people "current design and modification" but "two equal options" to get their opinion<br>
<TabAtkins> fantasai: +1 to Lea and Miriam's comments about ergonomics and consistency<br>
<TabAtkins> fantasai: I wanted to respond to Roman's comment about reusing @local in other contexts<br>
<TabAtkins> fantasai: this isn't a namesapcing mechanism, this is a different kind of construct<br>
<TabAtkins> fantasai: if we reused it, it wouldn't be a namespacing mechanism<br>
<lea> s/ lea: [missed]/ lea: one of the primary advantages of custom properties is their dynamic scoping and their cascading & inheritance. So we're basically reusing custom properties and throwing away the best things about them?/<br>
<fantasai> astearns: not hearing consensus<br>
<fantasai> TabAtkins: Options are spec as-is, or spell locals in some other way.<br>
<fantasai> TabAtkins: Doesn't seem like anyone wants to auto-insert @result<br>
<lea> I also think it's ok if L1 doesn't have extra locals (in addition to the arguments)<br>
<fantasai> astearns: Other ideas?<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to respond to kizu and to<br>
<TabAtkins> fantasai: Remind me what happens if you have multiple @results<br>
<TabAtkins> TabAtkins: last one (not in a false conditional) wins<br>
<TabAtkins> fantasai: so without @result, all of the contents would be output<br>
<TabAtkins> fantasai: I think it would be really obvious what's happening then<br>
<lea> q+<br>
<astearns> ack lea<br>
<fantasai> fantasai: You output everything, except what's hidden by @local.<br>
<fantasai> fantasai: That seems nice.<br>
<TabAtkins> TabAtkins: (note that most at-rules in CSS are last-wins)<br>
<fantasai> lea: I think we could ship L1 without locals.<br>
<fantasai> lea: And also, since we're rethinking this<br>
<fantasai> lea: if locals are like custom properties, then let's make them behave like custom properties<br>
<lea> s/L1 without locals/L1 without extra locals/<br>
<miriam> (we do have some at-rules that combine)<br>
<fantasai> lea: (we definitely keep arugments though)<br>
<fantasai> TabAtkins: Dropping locals doesn't make anything simpler<br>
<fantasai> TabAtkins: Locals themselves, it's not complicated. Just relation to return value is what we need to fix.<br>
<fantasai> s/fix/figure out/<br>
<fantasai> TabAtkins: Atm I would object to spelling differently from @function, so let's go back to issue for now.<br>
<lea> looks like we'll need another mixins breakout soon<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13524#issuecomment-4173368648 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 22:36:20 UTC