Re: [csswg-drafts] [css-mixins-1] Auto-wrap mixin body in `@result` if omitted? (#13524)

I’m very strongly against requiring an explicit `@result`, or any other solution that unnecessarily complicates the base case. Once they ship, mixins will be used all over the place. They will be used almost as much as variables (essentially they are how you do variables that span multiple properties). Tiny mixins would also be used to alias mixins so that multiple properties can be fed as input to components, in the same way as CSS variables are used today as input to components.

`@result` also serves no purpose in these cases. There is nothing to disambiguate. The complex case is getting in the way of the simple case, and while local vars are very useful, my prediction is that the simple case will be significantly more common. 

**I think, as a design principle, locals should not introduce any boilerplate to mixins that don't need locals.** Not just for ergonomics, but also strategically: it means simple mixins can ship first and locals can be implemented later, without simple mixins having this weird wart that only makes sense once complex mixins ship.

To be clear, I'm not a huge fan of auto-wrapping. It introduces [mode errors](https://en.wikipedia.org/wiki/Mode_(user_interface)#Modeless) where you don’t know what you have until you’re done reading the mixin. But (like you) I think it's the lesser evil.

That said, it may be worth exploring alternative syntaxes that preserve the design principle I listed above, while improving ergonomics for locals over `@local`. E.g., looking at the [previous syntax](https://github.com/w3c/csswg-drafts/issues/13138), it seems quite boilerplate-y that authors need to declare their intent to use a local multiple times. Why is that? Can they have a local variable and a regular variable with the same name, in the same scope? That seems rather confusing, which one does `var(--foo)` resolve to? 

What if they declared their local variables once with `@local` and then every instance of that variable in that scope was assumed to be the local? This would turn @andruud’s example from #13138 from this:

```css
@mixin --m() {
  @local --a: /* stuff */;
  @local --d: /* stuff */;
  @local --c: /* stuff */;
  @local --d: /* stuff */;
  @media (magnificence > 3.1) {
    @local --d: /* stuff */;
  }
  @local --e: /* stuff */;
  @supports (accent-color:red) {
    @local --e: /* stuff */;
  }
  @local --f: /* collecting all the above stuff */;

  & {
    color: var(--f);
    accent-color: var(--f);
    &::before {
      content: "Hi";
    }
  }
}
```

to this:

```css
@mixin --m() {
  @local --a: /* stuff */;
  @local --d: /* stuff */;
  @local --c: /* stuff */;
  --d: /* stuff */;
  @media (magnificence > 3.1) {
    --d: /* stuff */;
  }
  @local --e: /* stuff */;
  @supports (accent-color:red) {
    --e: /* stuff */;
  }
  @local --f: /* collecting all the above stuff */;

  & {
    color: var(--f);
    accent-color: var(--f);
    &::before {
      content: "Hi";
    }
  }
}
```

Which is still a little verbose, but O(N) on the number of variables, rather than O(Nk) on the number of variables × declarations that set them, so the verbosity is a little more contained. Perhaps there could even be a declaration-only `@local` that would support multiple variables:

```css
@mixin --m() {
  @local --a, --d, --c, --e, --f;
  --a: /* stuff */;
  --d: /* stuff */;
  --c: /* stuff */;
  --d: /* stuff */;
  @media (magnificence > 3.1) {
    --d: /* stuff */;
  }
  --e: /* stuff */;
  @supports (accent-color:red) {
    --e: /* stuff */;
  }
  --f: /* collecting all the above stuff */;

  & {
    color: var(--f);
    accent-color: var(--f);
    &::before {
      content: "Hi";
    }
  }
}
```

That is arguably *more* readable than the `@result` example because you know what you have upfront, does not introduce additional nesting levels like `@result` does, and does not introduce mode errors like auto-wrapping. It also mirrors function arguments nicely, which are implicit locals without having to be declared as such all over the place, and sidesteps all the open questions about where `@result` is and isn't allowed in listed at the end of #13138

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


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

Received on Thursday, 19 February 2026 16:28:47 UTC