[css-mixins-1] Behavior for multiple `@result` rules

[andruud]

This was brought up in #13138, but never fully addressed:

@mixin --m() {
  @result {
    div { color: green; }
  }
  @result {
    span { color: blue; }
  }
}

What is emitted from the above mixin? We seem to have two choices:

1. The last seen @result wins wholesale; only span{color:blue} is emitted.
   • It is consistent with how @thing foo generally overwrites a previous @thing foo in CSS.
   • It is consistent with how result works in @function.
2. All @result rules "accumulate" to form the output; div{color:green};span{color:blue} is emitted.
   • It is consistent with what @mirisuzanne expects.
   • TODO: Insert argument for this position.

[mirisuzanne]

• It is consistent with what @mirisuzanne expects.
• TODO: Insert argument for this position.

Lol. I think option 1 might be the right choice, I don't have a strong feeling that we need to go with option 2. But the argument for it is that @result is not a name-defining rule that needs to be resolved by choosing a winner. And accumulation matches many of the other rules in CSS – from media queries and container queries to name-defining layers. That's also how selectors work. Both options seem to me like well established patterns.

[SebastianZ]

Option 1 seems to be more flexible.

Example:

@mixin --m() {
  @result {
    div { color: green; }
  }
  @media (width >= 600px) {
    @result {
      span { color: blue; }
    }
  }
}

So I either get div{color:green} for viewport widths smaller than 600px or span{color:blue} when equal or bigger. This doesn't seem possible when accumulating them.

Sebastian

[mirisuzanne]

That's true. I think matching the behavior of the result descriptor is also a pretty good argument.

[andruud]

This doesn't seem possible when accumulating them.

Just place the conditional inside the result? (#13138 (comment))

[SebastianZ]

Well, yes. Though in that case the whole condition is returned by the mixin instead of just the styles.

Sebastian

[mirisuzanne]

Well, yes. Though in that case the whole condition is returned by the mixin instead of just the styles.

Is there any difference in that distinction?

[SebastianZ]

I think the outcome is the same, at least for now. Only if the result gets exposed via the CSSMixinRule interface, at some point, there will be a difference.

Sebastian

[tabatkins]

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 $results 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.

[mirisuzanne]

At this point I think either one is learnable and usable, so I don't have a strong opinion. I see advantages either way.