- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Fri, 14 Nov 2025 06:30:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-mixins-1] Expose environmental variables inside apply's contents block`.
<details><summary>The full IRC log of that discussion</summary>
<ydaniv> kizu: this depends on change from env vars to regular vars, moving to env vars simplifies things<br>
<TabAtkins> look at this example:<br>
<TabAtkins> @mixin --test(@contents) {<br>
<TabAtkins> --foo: pink;<br>
<TabAtkins> @contents;<br>
<TabAtkins> }<br>
<TabAtkins> <br>
<TabAtkins> button {<br>
<TabAtkins> --foo: lightgreen;<br>
<TabAtkins> @apply --test {<br>
<TabAtkins> background: var(--foo);<br>
<TabAtkins> }<br>
<TabAtkins> }<br>
<ydaniv> ... you can use custom props inside, and means that if you define them they are args to the mixin, and will be invisible inside it<br>
<ydaniv> TabAtkins: posted an example, mixin that sets foo<br>
<ydaniv> ... the element also sets foo<br>
<ydaniv> ... question is which color does it see? the one from the mixin sub?, can mixins shadow vars?<br>
<miriam> q+<br>
<ydaniv> kizu: in my opinion it's useful, however, if we want to explicitly say differently, when you look at the applied value from the side you don't know which one it will be<br>
<ydaniv> ... so either we could either use the one inside, but by default would be more useful to use the one outside, a bit confusing<br>
<ydaniv> TabAtkins: in this example it ends up light green<br>
<astearns> q+<br>
<ntim> my intuition would be either use inner, then outer (if inner is absent).<br>
<ntim> failing that, ignoring both is an option<br>
<ydaniv> ... agree it's possible the most obvious thing, content styles look more local, and if you have nested rule<br>
<ydaniv> ... you wouldn't want to change behavior<br>
<ydaniv> kizu: I think it's actaully pink there<br>
<ydaniv> ... because if you use it this way, because it's a registered custom property<br>
<kizu> https://www.irccloud.com/pastebin/D5y005wZ<br>
<ydaniv> TabAtkins: you're right, if the mixin took that var...<br>
<kizu> @mixin --test(@contents, --foo: pink) {<br>
<kizu> @contents<br>
<kizu> }<br>
<kizu> <br>
<kizu> button {<br>
<kizu> @apply --test {<br>
<kizu> background: var(--foo);<br>
<kizu> }<br>
<kizu> --foo: lime;<br>
<kizu> }<br>
<ydaniv> miriam: I think you're getting confused between what happens in impl and what we want<br>
<ydaniv> TabAtkins: yes, exactly<br>
<ydaniv> kizu: hard to tell from where something would come, and need to resolve it in some way<br>
<ydaniv> TabAtkins: in this example don't care about impl.<br>
<ydaniv> ... so ideally should not be pink?<br>
<ydaniv> kizu: yes<br>
<astearns> ack miriam<br>
<miriam> `@apply dark-colors { background: var(--from-mixin); }`<br>
<ydaniv> miriam: I agree we should with this, but counter for that I know in SASS it's different, where you have a mixin that defines stuff and then you psas a block and want an access to that<br>
<fantasai> +1 miriam<br>
<ydaniv> ... but agree that the default case would not be that<br>
<kizu> `@apply dark-colors using all { … }` maybe?<br>
<ydaniv> TabAtkins: in that case this behavior would be supported<br>
<ydaniv> miriam: ok<br>
<astearns> ack astearns<br>
<ydaniv> astearns: have an explanation... but now confused<br>
<ydaniv> TabAtkins: proposing for this behavior a contents block will see vars defined in the body of mixin,<br>
<ydaniv> ... but it will not see ones defiend in args<br>
<ydaniv> miriam: in several examples there's an @local<br>
<astearns> s/have an/had an/<br>
<ydaniv> TabAtkins: a local var acts a like arg but just not listed args list<br>
<ydaniv> miriam: in SASS that would not change the outside vars and access the inside, would that be possible?<br>
<ydaniv> ... not sure how important<br>
<ydaniv> kizu: I opened about this, regarding env vars, how do we access them<br>
<ydaniv> TabAtkins: it's still possible for us to add syntax for that<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to ask about the earlier example<br>
<ydaniv> fantasai: you had an example before, the contents passed in would have access to sutff in the body, but not parameters<br>
<ydaniv> TabAtkins: yes<br>
<ydaniv> fantasai: in that case the vars would be part of the output of the mixin<br>
<ydaniv> ... so if you wanted a set of vars that put in the mixin, then you would need to overide those say vars on where the mixin is used?<br>
<ydaniv> TabAtkins: yes<br>
<ydaniv> ... currently yes<br>
<ntim> It would be really useful for these kinds of issues to have all the possible combinations listed somewhere as a comment on the Github issue. Having to think through the combinations in your head highers the bar to contribution.<br>
<ydaniv> miriam: that's what I was saying, we could have extra syntax for that<br>
<ydaniv> TabAtkins: yes<br>
<ydaniv> astearns: more qs or examples?<br>
<ydaniv> TabAtkins: I think we got what we need<br>
<ydaniv> ... folks think it's a good behavior, got approvals<br>
<ydaniv> kizu: we should resolve after another related issue<br>
<fantasai> I guess one of the advantages of env() was that it could be clearer about what resolves against what<br>
<ydaniv> astearns: would like to get detailed examples of what we just talked about in the spec and why it works this way<br>
<ydaniv> TabAtkins: yes<br>
<kbabbitt> +1 astearns<br>
<ydaniv> ... I can do that<br>
<ydaniv> ntim: I think this issue is hard to reason about, right now trying to think about it and combinations and it's hard<br>
<ydaniv> TabAtkins: fair enough<br>
<ydaniv> astearns: moving on<br>
<ntim> (and we should get examples of combinations written on the issue)<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12631#issuecomment-3531103719 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 November 2025 06:30:18 UTC