- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Jan 2025 23:15:23 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-mixins] Improve ergonomics of `using` by allowing wildcards``, and agreed to the following: * `RESOLVED: Kill using with fire` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> TabAtkins: earlier I had implied that the interior of a fuinction can see custom props on element<br> <kbabbitt> ... questio is how should that be possible to what degree to make it automatic<br> <kbabbitt> ...current spec makes it not automatic at all<br> <kbabbitt> ... if you want to see custom props inside function you have to declare<br> <kbabbitt> ... then they become local varis inside function body<br> <kbabbitt> ... lea pointed out that doesn't work well in design systems with 100+ custom props<br> <kbabbitt> ... functions called by other functions also need to declare<br> <kbabbitt> ... lea's suggestion at first was to have some wildcarding syntax<br> <kbabbitt> ... but what I came around to instead was to remove that syntax entirely form fcuntion defintion<br> <kbabbitt> ... make all custom props visible inside custom function<br> <kizu> q+<br> <kbabbitt> ... arguments shadow if they have same name<br> <emilio> q+<br> <lea> strong +1 to TabAtkins' proposed behavior<br> <kbabbitt> ... my preference is to make all custom props behave similarly<br> <kbabbitt> ...nested variables visible in calling function in the same way<br> <kbabbitt> ... so you ca override when necessary but otherwise don't have to think about it<br> <lea> Way more flexible than the current syntax OR the wildcard syntax I proposed<br> <miriam> this matches my original proposal, and I like it :)<br> <kbabbitt> lea: the using feature is a wart in general, glad to be rid of it<br> <kbabbitt> ... makes a lot more use cases possible<br> <astearns> ack kizu<br> <astearns> q+<br> <kbabbitt> kizu: no objection, huge +1<br> <kbabbitt> ... only thing I want to mention is we could still keep using syntax if we want to allow renaming<br> <kbabbitt> ... variables from outer scope<br> <lea> q?<br> <kbabbitt> ... if we want to use same names in inner scope or as argument names<br> <kbabbitt> .... could using foo to define outer foo as something else<br> <lea> q+ to say this sounds like a L2 feature, and something we need more data on<br> <kbabbitt> ... other than that, having all custom props from outside available at all times would be much more useful<br> <kbabbitt> TabAtkins: already possible today if you declare a local var and set its value to var to pull from<br> <kbabbitt> ... probably don't need additional syntax for that<br> <kbabbitt> ... theoretically there for the future<br> <astearns> ack emilio<br> <kbabbitt> emilio: was wondering use case for this originally?<br> <kbabbitt> TabAtkins: I wanted to be careful about encapsulation<br> <kbabbitt> ... so you don't accidentally grab unintended variables<br> <kbabbitt> emilio: seems fine to allow it<br> <kbabbitt> ... from impl perspective, easy to compute set of variables if needed<br> <ChrisL> q+<br> <kbabbitt> ... manual list seems fine<br> <kbabbitt> TabAtkins: other aspect was, assuming we'll do a JS backed custom fn as well<br> <kbabbitt> ... at some point<br> <kbabbitt> ... using syntax made it clear exactly what would be passed to JS context<br> <kbabbitt> .. instead we'll gether all custom props, probably not a big deal<br> <lea> q+ to reply to emilio: do we even need to compute them? We can just propagate these `var()`s to the result and have the function return an expression that contains them<br> <kbabbitt> ...certainly easier to avoid massive repetition in JS than CSS<br> <kbabbitt> astearns: if it was a good optimization, you could take a look at what props were used and subset things when passing it over js boundary<br> <kbabbitt> TabAtkins: aliasing is a hard problem<br> <kbabbitt> astearns: to clarify: what happens when a custom prop is not defined?<br> <kbabbitt> ... and function is using it?<br> <kbabbitt> TabAtkins: it's just a var reference<br> <kbabbitt> ... you use the var syntax, same as anything else<br> <astearns> ack astearns<br> <astearns> ack lea<br> <Zakim> lea, you wanted to say this sounds like a L2 feature, and something we need more data on and to reply to emilio: do we even need to compute them? We can just propagate these<br> <Zakim> ... `var()`s to the result and have the function return an expression that contains them<br> <kbabbitt> lea: re: kizu - yes I can see potentially things to adjust how scoping works<br> <kbabbitt> ... possibly opposite of using and excluding vars<br> <kbabbitt> ... sound like level 2 features<br> <weinig> q+<br> <kbabbitt> ... don't want to expand scope right now, keep it lean so we can ship soon<br> <kbabbitt> ... re: emilio - do we actually need to compute the union of props being used?<br> <kbabbitt> ... just propagate var references instead?<br> <kbabbitt> ... if using vars from outside, instead of fn returning single value, could return an expression that includes var references<br> <kbabbitt> ... then they get resolved when used<br> <kbabbitt> emilio: didn't mean to imply they needed to be computed<br> <kbabbitt> ... looking at names fns are using, can see the names while parsing<br> <kbabbitt> ... join them when substituting<br> <kbabbitt> ...if we need for some super fancy optimization we could get that list<br> <kbabbitt> lea: awesome<br> <astearns> acl ChrisL<br> <astearns> ack ChrisL<br> <kbabbitt> ChrisL: I understand desire from CS standpoint to want to do data hiding<br> <kbabbitt> ... but in this case passing things it doesn't actually care bout but 8 level deep does care<br> <kbabbitt> ... passing them through produces less footguns<br> <astearns> ack weinig<br> <kbabbitt> weinig: to clarify.... using the programming language jargon, is what's provided here dynamic scoping?<br> <kbabbitt> TabAtkins: yes<br> <kbabbitt> weinig: where you call the function, element or scope there defines additional ?<br> <kbabbitt> TabAtkins: variable definition doesn't have meaningful scope<br> <kbabbitt> ...carrying on existing dynamic scoping of inheritance that custom prtops rely on<br> <kbabbitt> Proposed: Kill using with fire<br> <TabAtkins> s/meaningful scope/meaningful lexical scope/<br> <kbabbitt> RESOLVED: Kill using with fire<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10954#issuecomment-2623138036 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 January 2025 23:15:24 UTC