- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 29 Jan 2026 18:11:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-mixins-1] A var()-based model for mixin parameters`, and agreed to the following:
* `ACTION: Add a suggestion to the spec for the inspector to flag selectors that can't match`
* `RESOLVED: Accept the proposal`
* `RESOLVED: Add an unscoped mixin variant (syntax TBD)`
<details><summary>The full IRC log of that discussion</summary>
<bramus> TabAtkins: next 3 issues are all linked up here<br>
<bramus> … large rewrite of how weare doing mixins<br>
<ChrisL> s/cyril/cyrl/<br>
<bramus> … gonna do a rundown<br>
<bramus> … more specific discusssions can be done in the issue<br>
<bramus> … At TPAC I discussed som eof the change, but did not have visual presentation<br>
<bramus> … this should help show what is going on<br>
<TabAtkins> https://docs.google.com/presentation/d/1i-wOkEp9w91rmxTy2CaKzc0Sr_LC_qrko13TRnSjRMs/edit?usp=sharing (i'll send to www-archive in a bit)<br>
<bramus> … so, first topic is to make syntax more parallel to custom fns<br>
<bramus> … custom fns look like this<br>
<bramus> … name, params, local variables (custom props in the fn body, not exposed outside the fn), then result descriptor<br>
<bramus> … use var() inside the fn body to get to local vars, and then reach out outside<br>
<bramus> … old mixin syntax looked like this:<br>
<bramus> … params are the same, but then there wre local variables (scoped env var), and then you referenced both using env but for outside params you needed var()<br>
<bramus> … the entireity of the mixin body got subbed in, so tehre is no way to hide things to the outside<br>
<bramus> … this is going away<br>
<bramus> … (next slide)<br>
<bramus> … params the same now, local vars too. there is now a @result at-rule to indicate what gets exposed<br>
<bramus> … clear distinction between local and exposed<br>
<bramus> … can now use var() everywhere<br>
<bramus> … exactly like fns<br>
<bramus> … in vritually every way, mixins and fns now work the same way<br>
<bramus> … easier for authors to reason about<br>
<bramus> florian: so when you are trying to use insde the mixin tthings that are not locally or params, we fetch them from where?<br>
<bramus> TabAtkins: variables not catugh by local or arg, and get resolved based on where they are used<br>
<bramus> … they will take the correct --foo from the element where it is being styled<br>
<bramus> … so this thing here, is thing about making the return value more epxlicit using the @result<br>
<bramus> … does make small mixins more verbose to write<br>
<bramus> … but dont think this is a huge deal<br>
<bramus> … larger than it would be in sass, but gain in clarity to distinguish local vars vs vars you want to write in the styles is more clear now<br>
<bramus> … worth the cost<br>
<bramus> … (next slide)<br>
<iank_> Ding dong<br>
<bramus> … swapping variables from env to var was more complicated<br>
<bramus> … must be in a way that is transparant and intuitive to authors<br>
<bramus> … example here that is a mixin to set an element and its child to the same size<br>
<bramus> … passes 1em down to the child<br>
<bramus> … in the old model, it woudl sub the 1em into the styles for both<br>
<bramus> … would end up with parent being a calc with resulting different sizes<br>
<bramus> … old rough desugaring would result in 100px and 200p<br>
<bramus> … new way of doing it (this happens internally) is that we sub in th estyles but the props that get set (width) get rewritten in a new anonymous fhta reeturns that value<br>
<bramus> … let me walk through it:<br>
<bramus> … size gets internally renamed<br>
<bramus> … to magic-arg1 here<br>
<bramus> … same syntax and inherits<br>
<bramus> … then generate an anonymous fn<br>
<bramus> … takes the arg and produces the value<br>
<bramus> … produce the second one as well<br>
<bramus> … when we rewrite we start with the parent, lifts the argument value into the magic thing which gets resolved against the font size<br>
<bramus> … then the widt value is rewritten as the anonymous fn with the arg, returninng 100px<br>
<astearns> q+<br>
<bramus> … child does same thing, has font-size of 20px but we dont care … replace with the magic value returned<br>
<florian> q+<br>
<bramus> … so the two values are now identical<br>
<bramus> emilio: you would still get 1em in both if you omit the lenght right?<br>
<bramus> TabAtkins: yes<br>
<astearns> q-<br>
<bramus> florian: so you convince me that the geenrated code does the rigth thing here<br>
<florian> q+<br>
<bramus> … how did you get to it?<br>
<bramus> TabAtkins: essentially 3 bits<br>
<bramus> … take the body, all their values, and replace with anon fn, very trivial<br>
<bramus> … lets you resolve the references well based on the info<br>
<bramus> … then we also lift out the argument<br>
<bramus> florian: so you do 1 per invocation of the fns, but not the args?<br>
<bramus> TabAtkins: yes, only want to do that once<br>
<bramus> … if there are already local vars, that is part of the fn body as well<br>
<bramus> … which is why we have to fns, to carry around other stuff<br>
<bramus> … that is the big thing that andruud prototyped and is working very well<br>
<astearns> ack florian<br>
<bramus> florian: im convinced that it solves this use case/ how convinced are we that other use cases need this too?<br>
<bramus> … here you say you want the same length … and the hypothesis is that you want it<br>
<bramus> TabAtkins: correct. people could reasonably want other things<br>
<bramus> … solution now is to not type your variables<br>
<bramus> florian: reasonable answer<br>
<bramus> TabAtkins: could in the future add syntax for that<br>
<bramus> … there is space to allow for that<br>
<bramus> … most languages have an opt out<br>
<bramus> miriam: this relates to the issue I brought up yesterday, related to typing<br>
<bramus> TabAtkins: one aspect that is unfortunately required here is that mixins have to be scoped<br>
<bramus> … this example here does not work as written<br>
<bramus> … it takes a value and sets the widt on the element, child, and all ancestors<br>
<bramus> … kinda worked in the old model (probablly what you didnt want) but now no longer does<br>
<bramus> florian: doe snot work because the variable resolution uss the tree?<br>
<bramus> TabAtkins: var is resolved on l2. l1 cannot receive that (cyclic). doe snot work for 2 bc all selectors are implictly scoped to the element being applied … so this wont style the ancestors<br>
<bramus> … will only match and style l2 and 3<br>
<bramus> … in this model width of el2 and el3 will be 20px<br>
<bramus> … there might be reasonable reasons to style a parent or sibling<br>
<bramus> … there are ways around that<br>
<bramus> … the most stragithforward way is to rewrite the selectors so that you apply to the higher up element<br>
<bramus> … not perfect, but should work most of the time<br>
<bramus> … unfrotunately a strict requirement to makes this work<br>
<bramus> … possiblity to have ??? but then would lose all the other things<br>
<bramus> … would stop working<br>
<bramus> florian: why cant you?<br>
<astearns> s/???/unscoped mixins/<br>
<bramus> emilio: because you dont know what the em is until you style the parent<br>
<bramus> florian: the fact that you resolve the var on an el and its no tavalvaiable, i see<br>
<bramus> … but the fact that you have to apply scope?<br>
<bramus> TabAtkins: technically you woulndt have to have to<br>
<bramus> … you could styl e aparent aas long as you are not using any of the args<br>
<bramus> … here the var arg wouldnt be alloew to be set on the parent<br>
<miriam> q+<br>
<bramus> florian: this makes it predicatble and understanbable<br>
<emilio> q+<br>
<astearns> ack fantasai<br>
<bramus> fantasai: confused about the @scope stuff …interesting thing with the cascased, whcih author would not expect here<br>
<bramus> TabAtkins: I think I have it correctly in the spec (yesterda). intention is that we dont carry the cascading implications, only do the scoping<br>
<bramus> … (the filtering part)<br>
<bramus> fantasai: what is the benefit?<br>
<bramus> TabAtkins: prevents confusion<br>
<bramus> … (missed)<br>
<bramus> … that var wouldn texist<br>
<bramus> florian:so you uare making sure the rule isnt available whwere the variables are not<br>
<romain> q+<br>
<bramus> TabAtkins: so there is a chance we could add an tlernative form withotu the scoping thing (but prolly also without args)<br>
<bramus> … if we end up needing those, that is possible<br>
<bramus> fantasai: but seems unlikley<br>
<bramus> TabAtkins: yes, because most of the time you can lift things up<br>
<bramus> fantasai: gonna have to make that clear in the dfn<br>
<astearns> ack miriam<br>
<bramus> miriam: same logic does apply to siblings<br>
<bramus> … even if we had sibling scope, because we talk abou tscope of a var<br>
<bramus> … same solution as well?<br>
<bramus> TabAtkins: yes<br>
<florian> q+<br>
<astearns> ack emilio<br>
<bramus> emilio: this example here might not be amazing (its not typed) but if it were typed it would make it more clear<br>
<bramus> TabAtkins: yes, lack of typing<br>
<bramus> emilio: makes sense<br>
<bramus> … need to explain this very well<br>
<bramus> TabAtkins: yes, still some more spec clarification and examples that need to be done<br>
<bramus> … this model is been implemented by andruud and he’s happy with it<br>
<bramus> andruud: desugaring into custom fns is implemented, happy with that. scoping stuff and hygeinic rewrite not yet<br>
<bramus> emilio: a bit weird, because you cant really use th ecustom props machinery (to prevent leaks on css om)<br>
<bramus> … a bit messy<br>
<bramus> TabAtkins: I have a line that says “they are unobservable” that needs more details<br>
<bramus> emilio: stashin ganother hashmap makes me sad<br>
<bramus> TabAtkins: quite often you dnt need to dom ost of this … if its not typed, you can do direct style spamming<br>
<bramus> emilio: hard to prove though<br>
<bramus> … like weir dislinb combinator<br>
<bramus> … maybe not realistic<br>
<kizu> q+<br>
<bramus> TabAtkins: good thing is you dont need to be 100% correct … you can miss some<br>
<bramus> emilio: you can avoid optimizing some of the things, as long as you end up correct<br>
<bramus> TabAtkins: can andruud elaborate on how we omit some of the fns?<br>
<bramus> andruud: only case where we have an optimization right now is where there are no arbitrary substituion funcions<br>
<bramus> … not a lot yet<br>
<bramus> … would expect that this is fairly cacheable<br>
<bramus> … long mixing with complicated logic … all of those declarations are using same sset of locals<br>
<bramus> … could be cached<br>
<bramus> emilio: yes<br>
<TabAtkins> https://docs.google.com/presentation/d/e/2PACX-1vQvEiYo4d9N3-uL8vWIAfbipOfF42hE06lJ-l04HOaCfXiBHuhOmDFHFOvPHq9wjoXu6PprikhYsjVg/pub?start=false&loop=false&delayms=3000<br>
<bramus> … tricky, bu tnot all too concerned<br>
<TabAtkins> this work?<br>
<astearns> ack romain<br>
<bramus> romain: unfortuante about the scoping I think styling the next element or parent is the first thing authors would like to do<br>
<bramus> … since these vars arent addressable by authros, couldnt these be stored on a global map?<br>
<bramus> TabAtkins: no, the point of storing is that (if they are typed) they would be resolved on that element<br>
<bramus> romain: sure, but you could still uniquely address them<br>
<bramus> … but store in global map<br>
<bramus> emilio: effectively that ??? would be cyclic because value of thing would be maybe on you rchild and you need the parent style to inherit from<br>
<bramus> romain: but this invisible rsolved variable value would not inherit<br>
<bramus> florian: (agreeing with the q)<br>
<bramus> … resolve on element and sintead of stashing on the element, you use global var map<br>
<bramus> emilio: no. if you want to affect an ancestor, as soon as ancestor style affects … its not abou tthe var, anything that …<br>
<bramus> florian: fact that various props affect each other change tht<br>
<bramus> emilio: no, doesnt work<br>
<bramus> romain: dont we already have this problem without mixins?<br>
<bramus> TabAtkins: no, because custom props arent available on parents<br>
<bramus> emilio: this resolves at a very specific time<br>
<bramus> TabAtkins: if you want to style siblings, just lift the mixin 1 higher and put it on the parent<br>
<bramus> … bc you can use has to target the parent element, you should always be able to make that transform and move it 1 level up<br>
<bramus> romain: dont agree<br>
<bramus> … many cases where you dont know the surroundings but want to style the next one<br>
<bramus> TabAtkins: yes<br>
<bramus> … the selector for the parent is :has(parent)<br>
<fantasai> Archived Slide Deck:<br>
<fantasai> https://lists.w3.org/Archives/Public/www-archive/2026Jan/0003.html<br>
<bramus> … otherwise I could agree, but now we have has to solve that<br>
<astearns> ack florian<br>
<bramus> florian: thanks for explanations<br>
<bramus> … do suspsec thtat scoping makes some selectors not work would be mysterious … would be nice if there would be warnings about that (by tools)<br>
<astearns> @scoped-mixin<br>
<bramus> TabAtkins: agree that since mixin systems like that dont have this, this will be a point of confusion<br>
<bramus> … inspectorrs and notes inthe spec could help<br>
<bramus> fantasai: a note or suggestion would be helpful<br>
<bramus> TabAtkins: happy to take that as feedback to go<br>
<astearns> ack kizu<br>
<fantasai> ACTION: Add a suggestion to the spec for the inspector to flag selectors that can't match<br>
<bramus> kizu: i think i amo reagainst the scoping<br>
<bramus> … have situation where we dont have a good way that is not confusing to authors<br>
<bramus> … the selectors/rule sthat dont apply<br>
<bramus> … 2 points of confusion<br>
<bramus> … some reules for has() that dont work<br>
<bramus> … or the magically dispparing thing if we dont do scoping, only specific values are local vars<br>
<bramus> … in both cases we would use devtools help<br>
<bramus> … from athor pov I thin kmost wont use typed vars<br>
<bramus> … often use mixins without args<br>
<bramus> … and use stuf flike * + *<br>
<bramus> … or copy some css snippet<br>
<miriam> q+<br>
<bramus> … between tose two, having variable that resolve like for :has() or at IACT is better<br>
<bramus> … IACVT for non scoped … for things tha twould be cyclic,so you would have IACVT<br>
<bramus> … you would not have this var from anywhere, as its from el2<br>
<miriam> q-<br>
<bramus> … I think there are more use cases. if you omit length it will work, but don tknow if authors would know<br>
<bramus> … not scoping is sth that authors will expect more I think, rather than being scoped<br>
<bramus> … potentially throwing in more styles<br>
<miriam> q+<br>
<bramus> TabAtkins: point of correction: if we omitted length here, ti would not work in the other case<br>
<bramus> … wha twould happen here is tha twe take the uninterpreted 1em but bc of the desugaring, we try to apply to el1 and get a failed var reference making it IACVT<br>
<bramus> … it is not the typing hta tinvalides, its the desugaring<br>
<bramus> … <missed> we need it to desugar differently. a mixin unscoped that changes the desugaring rules (no arg lifiting, no fn rewrite) could work but we cant do it automatically<br>
<bramus> … cant have anything that works reasonably in the desugaring work<br>
<bramus> … ???<br>
<bramus> kizu: this case here could b esolved with the global hash<br>
<bramus> TabAtkins: yes, in theory<br>
<bramus> kizu: you could potentially do romain’s global hash thing. Just store token 1em and width on el1 would get value from env var<br>
<bramus> … not simply and differentiation<br>
<bramus> andruud: wasnt romain saying tha twe shoul dnot scope at all here?<br>
<bramus> kizu: yeah<br>
<bramus> andruud: tha twould apply some width here?<br>
<bramus> kizu: I think tab says that we desugar as magical var<br>
<bramus> … and bc we define on el2 it is not avilable on parent<br>
<bramus> … unelss we could desugar to apply on eery element that we define here<br>
<bramus> andruud: if we dropped scoping, then the width on el1 should resovle to something here<br>
<bramus> TabAtkins: el1 10px, el2 20px, …<br>
<bramus> andruud: if we drop scoping then el1 should ge ta valid width here<br>
<bramus> TabAtkins: yes<br>
<astearns> ack miriam<br>
<bramus> miriam: somewhat related<br>
<bramus> … in terms of what we talked about: controls over changing the type<br>
<bramus> … once you capture a value, you cant uncapture<br>
<bramus> … no way to get back from px to 1em<br>
<bramus> … i think the orig proposal here over-indexes on that we want the same value here<br>
<bramus> … dont think that is ncessariy the common use case<br>
<bramus> … I like an approach that prioritizes this sort of thing and if that helps avoid scoping tha tis great<br>
<bramus> … and then can use the capturing fns in a more limited way<br>
<bramus> … and those can be IACVT<br>
<bramus> TabAtkins: today you can get that behavior if you dont type your args<br>
<bramus> … they are left uninterpreted<br>
<bramus> … 1em stays 1em<br>
<bramus> miriam: I think that is good<br>
<bramus> TabAtkins: we still end up applyin gth escoping, bc of desugraging parent would fail to get all styles (IACVT)<br>
<bramus> … if we did want to go fully unscoped, we need an implicit flag because it changes desugaring<br>
<bramus> … cant automatifally do it<br>
<bramus> … as long as you are ok with scoping applying, you can choose an arg to be left as is or not, on a case to case basis<br>
<bramus> miriam: definingint he typ eon the param is basically a shorhtand for at call time using a fn to set the type<br>
<bramus> astearns: so we had the overall presentation<br>
<bramus> … been having a good conversation about scoping ¬ which is a sepaate issue<br>
<bramus> TabAtkins: the three issues were tied into this one presentation<br>
<bramus> astearns: sounds like there is a preference to remove the scoping requirement<br>
<bramus> TabAtkins: dont think we heard that<br>
<bramus> astearns: romain and miriam?<br>
<bramus> miriam: what I way saying is that if scoping is mostly abou tgetting taht ability to capture, i don thtink that is important enough to add the scoping restriction<br>
<bramus> TabAtkins: it is required for a few subtle aspects of this<br>
<bramus> … not jsut type capturing<br>
<astearns> s/romain and miriam/romain, roman, and miriam/<br>
<bramus> … in order to make them work at all levels, we also need tha tsort of scoping, some things otherwise get lifted there<br>
<bramus> … the desugaring I described that ends up effectivley scoping is needed for sevearl apsect<br>
<bramus> … doing the unscoped is possible, bu tthen some things do not work the same way<br>
<bramus> … large change<br>
<kizu> q+<br>
<bramus> … like I said, totally possible to add a flag to mixins that causes them to desugar differently, but means that if you are not careful you could very easily end up writing bad code that does not do what you want it to do, but can also write sass-like mixins<br>
<bramus> … this goes beyond ems<br>
<bramus> … if you use var(--foo) on el2, you want the value from el2, not the rest<br>
<bramus> … this is the exact same problem as ems here<br>
<bramus> … in general the desugaring tha timply scoping is almost always th eright thing to do, and you can escape it by using untyped variables<br>
<bramus> … if we still end up wanting a fully unscoped thing, that is possible … want to try and see how far we can go without that first<br>
<astearns> q+<br>
<bramus> … it is in scope of the spec to do an unscoped mixin<br>
<bramus> kizu: random idea<br>
<astearns> ack kizu<br>
<bramus> … would be great to have both<br>
<bramus> … one thought how to express this, is maybe … we were thinkgina bout making @result optional … so we need @result for local vars<br>
<bramus> … only posible when its scoped<br>
<bramus> … so what if you omit @result it is unscoped<br>
<bramus> … if you add it, it is scoped<br>
<bramus> … once you add it, its mcuh easier to say that it behavs differenly<br>
<bramus> … cannot use siblings and stuff<br>
<bramus> … in addition could disallow thyping when there is no @result<br>
<bramus> TabAtkins: not just local vars, also how args need to resolve<br>
<miriam> that feels a bit implicit to me, doesn't clearly express what's happening<br>
<bramus> … even her in this case iwth an untyped argument with a variable, you would expect it toread it from the element<br>
<bramus> … with unscoped it would not do that<br>
<bramus> … you are very loathe to make it implicit<br>
<bramus> … want it to be explicit<br>
<bramus> … bc you cant have local vars when unscoped<br>
<romain> agree that it is better to be explicit, easier to teach authors and look it up if you encounter it in source code<br>
<bramus> …we proally can omit the @result (prolly with @unscoped-mixin)<br>
<bramus> … if we do it, we could make them virtually identical to how you would write them in sass<br>
<bramus> … module the naming patterns<br>
<bramus> kizu: if we do both, it would be important to ship both at the same time<br>
<bramus> … so that people dont shoot themselves in the foot with the other (shipped) version<br>
<bramus> TabAtkins: fair and given that we dont do a bunch of fancy rewriiting in the unscoped one, that sounds feasible<br>
<bramus> astearns: here to reinfoced kizus point<br>
<bramus> … if we do both, we might want to make them unscoped by default<br>
<bramus> TabAtkins: disagree<br>
<bramus> astearns: from a learning perspective … could make @mixin unscoped and add @scoped-mixin<br>
<bramus> TabAtkins: reason I disagree I thik people will do things like accessing custom prop in a mixnig form an alement<br>
<bramus> astearns: peole are already use to using vars in different context and having them resolve differently<br>
<astearns> ack astearns<br>
<bramus> TabAtkins: when those contexts are visible, yes<br>
<romain> q+<br>
<bramus> …with an @apply you dont see the context<br>
<bramus> … would probably expec that I am writing there to ???<br>
<astearns> ack fantasai<br>
<bramus> fantasai: kizu argumented that unscoped does the simple thing … so kizu was saying @result could be a trigger<br>
<bramus> … what is your objection?<br>
<bramus> TabAtkins: very subtle syntax distinction. easy to do by accident. a lot of times forgot to add @result myself (because its a new thing to me)<br>
<bramus> fantasai: why is that less of an obivius signal?<br>
<bramus> … rahter than a keyword<br>
<bramus> TabAtkins: a keyword there would say scoped or unscoped or sth like that<br>
<bramus> fantasai: so @result by virtue of behing an at-rule that contains the rules that get returned … like blocks that createa scope for some kind of purpose<br>
<bramus> … not sure if that is non-obvious<br>
<bramus> … scope as akeyword here could get mixed up with @scope<br>
<bramus> … so if we use scoping here with a keyword, it might imply we do @scope but we dont<br>
<bramus> … leaning towards more what kizu is saying: the @result is the trigger<br>
<bramus> TabAtkins: the @result doe snot indicate anything<br>
<bramus> … nothing about the word says that it is processed differently<br>
<bramus> … the name mirrors the result descriptor from fns<br>
<romain> +1 to using an explicit and self explaining flag<br>
<bramus> fantasai: is there any other effect other htan cutting of what matches? doe sit change computation?<br>
<bramus> TabAtkins: yes, massively: int his case here --foo is not resovled ont he element that its being applied to (el2) but now will resolve to whathever the var is<br>
<bramus> fantasai: so resolving things differnelty and trimming the selector<br>
<bramus> florian: these are not two independent effect<br>
<kizu> `@resolve {}`<br>
<bramus> fantasai: so the fact that its applying scoping is prolly not the biggest difference but the computation<br>
<bramus> TabAtkins: yes<br>
<bramus> fantasai: so its not really about scoping …<br>
<bramus> TabAtkins: right. if you have a better word here …<br>
<bramus> fantasai: should come up with a better one<br>
<bramus> … dont think we need an extra keyword int he prelude<br>
<bramus> andruud: should we do something on the apply side instead?<br>
<bramus> florian: is there vocabulary for this?<br>
<bramus> TabAtkins: standard macro<br>
<astearns> ack romain<br>
<bramus> romain: the @result didnt get much detail in the presentation, but is in the issue … how does it interact with apply? only allowed iwhtin results? are local vars outside of @result? avialble in nested mixins? stuff like that …<br>
<florian> q+<br>
<bramus> TabAtkins: can definitely @apply more mixins insid ea mixin … needs to be in @result<br>
<bramus> … its a nested declarations block<br>
<bramus> … it can take things like @apply<br>
<bramus> … outside of @result its not<br>
<bramus> … simliar to fns, limted to what it can accept<br>
<lea> q?<br>
<lea> q+<br>
<bramus> … when you sub in (fi you call a mixin) insnide @result, if that one exepected a var from higher up the chain it can see a local var from the outer mixin<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<bramus> … it an intercept outer vars just like in fns<br>
<bramus> romain: is it required to use @result?<br>
<bramus> … but people might find it annyoing<br>
<bramus> … could we allow omission?<br>
<bramus> TabAtkins: that is the confusion part I want to avoid<br>
<bramus> … could have a mixin whose only effect is to define a few variable<br>
<bramus> … thus ther ei sno syntactic distinction between local vars and custom props you want to apply on the element<br>
<bramus> … need a syntactic flag: that is the @result block<br>
<bramus> romain: for CSS OM it is better tha tthese are well defined and not dynamic<br>
<bramus> TabAtkins: very much so<br>
<bramus> … the rule prolly gonna be readonly<br>
<bramus> … regardless certainly a lot easier<br>
<florian> q?<br>
<astearns> ack florian<br>
<bramus> florian: trying to find different ways of talking about this<br>
<bramus> … hygeienic is wrong word<br>
<bramus> … one is a literal mixin, and the other one a resolved one<br>
<bramus> … distinguish not in the definition, but in the application<br>
<bramus> … (like andruud suggested)<br>
<bramus> TabAtkins: plausible<br>
<bramus> … should add the mechanism for usncoped, and should discuss how to do that<br>
<bramus> … should figure out what the synatx should be there<br>
<bramus> miriam: might want to distinguish at defintion time<br>
<bramus> TabAtkins: yeah, double opt-in … difference are important enough to call out<br>
<bramus> fantasai: dont think user casers about how its computing. its the person defining it most likely<br>
<bramus> florian: fair<br>
<bramus> TabAtkins: not looking to decide on that now. can talk about it later<br>
<astearns> ack lea<br>
<bramus> lea: the @result is userful for syntacitcally distinquicshing local vars<br>
<bramus> … vs what is exposed<br>
<bramus> … many mixins have no such distinction<br>
<bramus> … only reason you creat ethe mixin is to abstarct stuff<br>
<bramus> … would be very annoyoing to have to nest that twice<br>
<bramus> … becomes boilerplate<br>
<bramus> TabAtkins: agree<br>
<bramus> lea: wonder if we could just assume the entire mixin is exposed if there is no @result<br>
<bramus> … even can do it in cssom<br>
<kizu> +1 to that<br>
<bramus> TabAtkins: for unscoped agree that we should not require it<br>
<bramus> … for scoped im at least weakly to moderata against that syntax-??? would not object, but would prefer to keep syntax consistent<br>
<bramus> … so that its obvious for the person reading it what it does<br>
<bramus> … condition can be in the body, and result in the @result<br>
<bramus> … not clear immediately otherwise to know what syntax branch you are in<br>
<bramus> lea: seems like the only things we can put outside are varaibles?<br>
<bramus> TabAtkins: and conditionals<br>
<bramus> TabAtkins: the @result can also be in the condition<br>
<bramus> lea: ????<br>
<bramus> TabAtkins: anything like you put in a custom fn<br>
<dbaron> s/in the condition/in the conditional/<br>
<bramus> lea: but custom fns are only varaibles?<br>
<bramus> TabAtkins: you can define them, and use condtiioanls to define the result condtionally<br>
<bramus> lea: its still basically only private vars<br>
<bramus> astearns: the conditianls can also result a result<br>
<bramus> lea: i am talking about outside the result<br>
<bramus> … eseentailly in terms of observable things, its only vars that we are hidning<br>
<astearns> s/also result/also include/<br>
<bramus> … so that instead of requiring an @result, one could mark a variable as private<br>
<bramus> … so no nesting<br>
<bramus> TabAtkins: that is a suggestion in the thread<br>
<bramus> … suggestion there was to write locals as `@local --foo: bar`<br>
<miriam> q+<br>
<bramus> … possible<br>
<bramus> … but I think its useful for authors to have overlap between how you write custion fucntions and mixins<br>
<bramus> lea: I thkn that something around this would be better, because mental model for mixins is ???<br>
<bramus> … @result is an additional step<br>
<bramus> … designed around you ahve private things, and want to expose<br>
<astearns> with @local you can interleave local things and the output<br>
<bramus> … I think mixins are the other way around<br>
<bramus> TabAtkins: agree that using local vars in a mixin is prolly gonna be less common thatn reslyin gon args<br>
<bramus> miriam: Anecdtoally I already saw someone doing a video about it, and their reaction was that @result does the same as the result descriptor.<br>
<bramus> … was chris coyier<br>
<bramus> TabAtkins: that is exactly te mental recotextualization I want to hit here<br>
<bramus> lea: seems like a nice to have<br>
<bramus> TabAtkins: neither trumps the other<br>
<bramus> lea: important that we get it right and that its effcitient<br>
<bramus> TabAtkins: remember that I mentioend we proabley should add unscoiped, which dont have local vars<br>
<bramus> lea: but having two types seems more inconsistent<br>
<bramus> TabAtkins: not particularly<br>
<bramus> astearns: what can we accomplish today?<br>
<lea> s/lea: but having two types seems more inconsistent/lea: but having two types of mixins that are inconsistent with each other seems like a bigger inconsistency than mixins not being consistent with functions/<br>
<bramus> TabAtkins: propose reso are: we accept these changes (still early spec) and then additionally that I add the unscoped variant and open an for how we name/invoke these two concepts<br>
<bramus> … and to what degree their syntax is identitical or diverges<br>
<bramus> florian: so resolving on accepting the behavior, but keeping the syntax open<br>
<bramus> TabAtkins: yes<br>
<lea> +1 to exploring the problem space, but strong reservations on the syntax<br>
<bramus> florian: works for me<br>
<bramus> astearns: any concerns about accepting the scoped mixin along with anunscoping getting specified?<br>
<bramus> … this is covering all thre issues?<br>
<bramus> TabAtkins: 3/4<br>
<bramus> … relevant, but ???<br>
<bramus> astearns: objections?<br>
<bramus> RESOLVED: Accept the proposal<br>
<bramus> RESOLVED: Add an unscoped mixin variant (syntax TBD)<br>
<bramus> astearns: and outlining the differences needs to be very clear<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12927#issuecomment-3819365691 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 January 2026 18:11:30 UTC