[css-mixins-1] When does (custom) `env()` resolve?

[andruud]

When a (custom) env() is used in a declaration inside a mixin, when do we expect that to resolve? Example:

@mixin --m(--color) {
  & {
    color: env(--color);
  }
}

Currently, env() resolves computed-value-time, together with var() and other arbitrary substitution functions. To maintain that, we'd need to "remember" which mixin rule encloses us until computed-value-time. (Which may become even harder depending on what we decide for #12675.)

Or, we could specify that these env() functions resolve at @apply-time, but that would mean that the later stages of the pipeline is unaware that an env() ever existed there---I'm not sure if this has any unintended consequences or not. At minimum, we need to define what happens when an @apply-time env() becomes IACVT (IAAT = invalid at apply time?), because we cannot treat a declaration as unset at that point:

@mixin --m() {
  & {
    color: env(--invalid); /* What now? */
  }
}

[andruud]

If they substitute @apply time, they won't automatically interact well with features that "act" on IACVT, for example:

@mixin --m() {
  & {
    color: first-valid(env(--invalid), var(--thing));
  }
}

I think we'd need to add a CSS-wide keyword (guaranteed-invalid?) and have env() resolve to that.