- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 25 Mar 2026 16:02:56 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-mixins-1] Behavior for multiple `@result` rules``, and agreed to the following: * `RESOLVED: Last one wins` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> TabAtkins: question is, what happens if you have multiple @result rules inside a mixin?<br> <kbabbitt> ... is it valid, and if valid, what happens?<br> <kbabbitt> ... if it's not valid, only one @result, nice and simple<br> <kbabbitt> ... if you have 2 @result rules could either merge, or you could have last one wins<br> <kbabbitt> ... those are the 3 possibilities. only one, multiple and merge, multiple and last one wins<br> <romain> q+<br> <kbabbitt> ... argument for allowing multiple is that we can allow e.g. @media queries inside mixin body<br> <kbabbitt> ... only way that would be useful is if difrferent conditional rules each had @result in them<br> <lea> q+<br> <kbabbitt> ... nice to be able to say if screen is wider than 800px emit this rule, otherwise emit other<br> <kbabbitt> ... leans us slightly towards last one wins interpretation<br> <kbabbitt> ... if you merge them all, when screen is wider than 800px, you get both<br> <romain> +1 to that<br> <kbabbitt> ... only way to avoid would be to put all results in mutually exclusive conditions<br> <kbabbitt> ... not usually what authors rely on<br> <kbabbitt> ... my preference is somewhat towards allowing multiple result rules and having last valid one win<br> <kbabbitt> ... last one in true conditional<br> <andruud> +1<br> <kbabbitt> ... could go either way<br> <florian> +1<br> <kbabbitt> ... happy to just merge them all, also works okay but requires slightly different menal model<br> <kbabbitt> ... relatively strongly against requiring a single @result<br> <romain> q-<br> <kbabbitt> ... would mean no purpose to conditionals aty all<br> <lea> q-<br> <kbabbitt> ... would only allow you to set local vars differently<br> <kizu> q+<br> <kbabbitt> +1 to last one wins<br> <lea> +1 that we should allow multiple and have a sensible way to deal with it. Still unsure what that is.<br> <kbabbitt> kizu: commented today 2 hours ago, okay with anything, one potential case where merging is better is if we allow using additional ? outside @result for overriding local vars<br> <kbabbitt> ... makes sense to use condition for local var but not produce @result, could produce one result in one conditional another in another could potentially merge<br> <kbabbitt> ... would be closer to how function works<br> <kbabbitt> ... result value which is only one<br> <kbabbitt> astearns: I thought it might be the case that if we just let last one win, you could get the merging behavior by defining local vars in conditional that you use in last result<br> <kbabbitt> ... but what kizu said made methink that's wrong?<br> <kbabbitt> kizu: could define local vars inside result,<br> <kbabbitt> ... don't think we allow conditionals outside @reuslt?<br> <kbabbitt> TabAtkins: conditionals sould work outside @result but only affect which ones are valid<br> <kbabbitt> ... and what local var values are seen<br> <kbabbitt> ... you can move the conditional into the @result at which point it becomes party of style rule taht's emitted<br> <kbabbitt> ... if you want to adjust local vars based on that, you either have to repeat MQ outside @result, or don't use local vars, instead use real custom props adjusted by MQ inside @result<br> <kbabbitt> ... can do it 2 ways, they have tradeoffs<br> <kbabbitt> ... that use case is possible in a few variations<br> <lea> TabAtkins: I think it would be useful to see those code examples in the issue<br> <kbabbitt> astearns: we are a bit over time, can we resolve on last one wins?<br> <romain> +1<br> <kbabbitt> ... objections?<br> <kbabbitt> RESOLVED: Last one wins<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13522#issuecomment-4127807374 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 March 2026 16:02:57 UTC