Re: [csswg-drafts] [css-mixins-1] Behavior for multiple `@result` rules (#13522)

Option 1 was my original argument, too. I changed to accumulation based on feedback from Miriam. ^_^

The consistency with `result` in `@function` is compelling from a learning perspective, I agree. Beyond that:

* using a conditional in the body already conditions whether the included result will be merged into the final result
* letting two top-level `@result` values doesn't help you; you can just merge them yourself when authoring the mixin
* the *useful* question is whether a top-level `@result` and a `@result` in a true conditional should be merged or override, and similarly whether the `$result`s of two separate true conditionals should be merged or overridden

I think the first of those "useful questions" (`@result {A} @media (...) { @result{B} }`) leans us toward overriding, for the consistency with 'result', but I think the second (`@media(...) { @result {A}} @media(...) { @result {B}}`) might have a stronger argument for merging. The two MQs might be doing completely different things, for example, and combining their possibilities requires combinatorial nesting. On the other hand, that "combinatorial nesting" is something we already have to handle with MQs in all other contexts, so trying to "solve" it in a special-case here might not be worthwhile. (We should instead handle it with better chaining/combining functionality for conditionals; we have an older set of issues about this.)

So if Miriam is okay with it, I'd be happy to switch back to "last wins" for `@result` rules.

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


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

Received on Tuesday, 3 March 2026 17:52:02 UTC