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

> is that indeed desirable behavior from the perspective of `--bar`?

Hmmm. Good point. I guess, possible solutions, brainstorming some ideas:

1. Make local env variables be “closer” than those exposed from the mixin. Because you're in a context you control, if there will be conflicts, you could just rename things. But it could feel pretty awkward.
2. Have some syntax for `@apply` where you'd need to explicitly define names of inner env variables that you're using, like `@apply --foo using --test` or something. Unless you define it this way, a local env will be used.
3. Instead of some kind of param in `@apply`, this could be a special at-statement to be used inside the `@apply` block, like `@apply { @using --test, --test2, --etc; background: env(--test) }` 
4. Have a special version of `env()` like `inner-env()` or with some other name.

I think the solution is somewhere here, basically have some way to differentiate/define them.

> > I don't see use cases that would require the opposite.
> Having a shared intermediate result between stuff in @apply-blocks and elsewhere in the mixin?

Yeah, options are: we make all `@env`s available inside the `@apply` in one way or another, _or_ we make them private by default, and have some syntax for `@contents` that will define the envs that are available for the `@apply` block, like `@contents using(--test);` or something.

-- 
GitHub Notification of comment by kizu
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12631#issuecomment-3403895571 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 14 October 2025 22:59:29 UTC