Re: [csswg-drafts] [css-mixins-1] Expose locals inside apply's contents block (#12631)

The CSS Working Group just discussed `[css-mixins-1] Expose locals inside apply's contents block`, and agreed to the following:

* `RESOLVED: Contents blocks don't interact with the private variables of the mixin. Investigate allowing that in the next level.`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> TabAtkins: We have a DIV setting custom properties on itself. It then calls a mixin, both passing one of those custom properties as a param<br>
&lt;fantasai> ... and also passing an @contents block referencing that variable.<br>
&lt;fantasai> TabAtkins: Is this var() in the contents block always resolving against the DIV's own --a, or--if the mixin defines its own --a--can the contents block reference that?<br>
&lt;bkardell> gold<br>
&lt;bkardell> ⭐<br>
&lt;fantasai> div { --a: gold; @apply --bar(var(--a)) { --coor: var(--a); } ; }<br>
&lt;fantasai> TabAtkins: The two var references are close to each other. Seems like they should resolve the same way.<br>
&lt;fantasai> TabAtkins: On the other hand, there are use cases for being able to pass in a block that relies on variables that the mixin sets up for it.<br>
&lt;fantasai> TabAtkins: 2 parts of my proposal<br>
&lt;lea> q+<br>
&lt;fantasai> TabAtkins: 1. By default, if you write this, that var() will never reference anything inside the mixin.<br>
&lt;fantasai> TabAtkins: Nothing defined in the mixin will influence the contents of the contents block.<br>
&lt;fantasai> TabAtkins: 2. If you do want to resolve against the mixin body, then add some new syntax ('using --a') to evaulate against the mixin body.<br>
&lt;fantasai> TabAtkins: That would allow you to resolve against the injected context.<br>
&lt;kizu> q+<br>
&lt;astearns> ack lea<br>
&lt;fantasai> lea: I'm finding it very hard to figure out what happens without seeing the mixin.<br>
&lt;lea> scribe+<br>
&lt;lea> lea: If we have a mixin that uses the `@contents` block inside a descendant that has a different `--a` value, which one would it get?<br>
&lt;fantasai> TabAtkins: Is this the question? [screen] Contents block is styling your variable.<br>
&lt;miriam> q+<br>
&lt;fantasai> TabAtkins: In this case, the answer is, that --a would not be captured by the var(). It would resolve normally, so it would grab the tomato from the span.<br>
&lt;fantasai> lea: Locals of mixin should be mixin implementation details. Feels weird for contents block to have access to it.<br>
&lt;astearns> ack kizu<br>
&lt;fantasai> TabAtkins: There are use cases for it, but I think I also prefer to defer that functionality to level 2 becuase it's complex<br>
&lt;fantasai> kizu: OK to defer this to L2.<br>
&lt;kbabbitt> +1 that mixin locals should be local to the mixin<br>
&lt;fantasai> kizu: This is something that can be very useful.<br>
&lt;fantasai> kizu: Mixin could expose a number of useful tools inside that you could use on your elements.<br>
&lt;fantasai> kizu: but I agree that by default that authors wouldn't expect to access those<br>
&lt;fantasai> kizu: Opting in would be better.<br>
&lt;fantasai> kizu: I like 'using' syntax. Especially having 'all'.<br>
&lt;astearns> ack miriam<br>
&lt;fantasai> kizu: But agree with moving to L2 and do expected thing for authors now.<br>
&lt;fantasai> miriam: Deferring is fine. Just to overcomplicate the example we have on the screen<br>
&lt;fantasai> miriam: It's possible that we change the value of --a in the mixin, but not in the part of the mixin where the contents block is being used.<br>
&lt;fantasai> miriam: we change it not as a local but as an output<br>
&lt;fantasai> TabAtkins: Yes, that would be visible.<br>
&lt;fantasai> miriam: So we're not saying that the contents of the mixin can't affect the var, only the *private* internals have no impact<br>
&lt;fantasai> TabAtkins: right<br>
&lt;fantasai> PROPOSED: Contents blocks don't interact with the private variables of the mixin. Investigate allowing that in the next leve.<br>
&lt;fantasai> RESOLVED: Contents blocks don't interact with the private variables of the mixin. Investigate allowing that in the next level.<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-4172934882 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 20:59:35 UTC