- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Fri, 14 Nov 2025 06:12:42 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-mixins-1] A var()-based model for mixin parameters`. <details><summary>The full IRC log of that discussion</summary> <ydaniv> TabAtkins: just intro-ing this topic<br> <ydaniv> ... current spec for mixins, for some reasons, it has to handle args to mixins in speciial way<br> <ydaniv> ... can't just use var(), becaue the body is passed to another rule and you don't want to pollute other stuff<br> <ydaniv> ... so I difined a new idea of scope<br> <ydaniv> ... it kanda works, have some issues<br> <ydaniv> ... and we thought of another idea<br> <ydaniv> ... effectively when you apply a mixin, we do a funky inversion where you end up with a lot of anonymous functions in the leaf property values<br> <ydaniv> ... where you have a behavior where they interleave in a nice way<br> <ydaniv> ... so not inventting a new way to invoke funcitons<br> <ydaniv> ... makes it work substantially better, may have some odd implications<br> <ydaniv> ... helps a lot with caching<br> <ydaniv> ... we used YOUTUBE as test case<br> <ydaniv> ... so letting ppl know that we're experimenting with it, very happy about it internally<br> <lea> q+<br> <miriam> q+<br> <kizu> +1<br> <ydaniv> ... if there are no objections, would like to change spec to this new model<br> <ydaniv> lea: based on this summary, not sure what is proposed<br> <ydaniv> ... very hard to say whether we object<br> <ntim> +1 to lea<br> <ydaniv> TabAtkins: this is just an intro<br> <ydaniv> ... in the linked issue there are more details<br> <fantasai> +1 to lea<br> <astearns> ack lea<br> <astearns> ack miriam<br> <ydaniv> miriam: I think would be helpful to have comments on implications, not just impl. details<br> <ydaniv> TabAtkins: the author facing implications, A: not introducing a new arg for custom funcs and var, they look similar<br> <ydaniv> ... B: this makes variables passed to mixins work better, to some extent<br> <ydaniv> ... in most cases did not work in previous model<br> <miriam> q+ to finish my thought<br> <ydaniv> ... there are some limitations still, like how geenric macro works<br> <ydaniv> ... but upshot is, in general case, maybe all, passing variables in should work<br> <ydaniv> ... and same authoring model<br> <astearns> ack miriam<br> <Zakim> miriam, you wanted to finish my thought<br> <ydaniv> miriam: and there are also implications that you can only impact decendants?<br> <ydaniv> TabAtkins: not necessarily, if I want to add a restriction that it acts like it's scoped<br> <ydaniv> ... if you don't apply it then, if you select above or siblings, they may work differently<br> <ydaniv> .. it's a bit of a footgun if you want to allow unscoped mixins<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask what impact this has on people using mixins<br> <ydaniv> miriam: will have to look into it more<br> <ydaniv> fantasai: what is the look path for foo variable?<br> <ydaniv> TabAtkins: similar to custom functions, mixins also introduce hypothetical elements<br> <ydaniv> ... so if you in the simple cases ...<br> <ydaniv> fantasai: from the element you apply from?<br> <ydaniv> TabAtkins: this comes to discussion on scoping or not<br> <ydaniv> fantasai: if I take a code block and apply a mixin, if I ask for element foo do I get same element? or looking it up on the applied?<br> <ydaniv> TabAtkins: you first use where you apply, the walk up the tree<br> <ydaniv> astearns: we have this proposal, and impl behind flag you can try out<br> <ydaniv> miriam: we can play with it in canary?<br> <ydaniv> TabAtkins: yea<br> <ydaniv> astearns: moving on<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-3531037837 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 November 2025 06:12:43 UTC