[css-mixins] Improve ergonomics of using by allowing wildcards
#10954
Comments
|
I'm slightly against this. The use-case is reasonable, but I think we should solve it more directly. Basically, a function knows exactly what variables it is going to use. There's no need to import every single color; just write the ones you're actually using in your The problem is that a function doesn't know what theming variables its own called functions will want to use, and so pulling in the entire theme, as in your example, makes sense. This means it would probably end up being common practice to just write We do want to make sure that an outer function can override a theming variable for the functions it calls (and the functions they call, etc, if they're not further overriden). This sort of theming control is important. Maybe Here's an example: @function --outer() {
--v1: 10;
result: --inner();
}
@function --inner() using (--v1: 100, --v2: 200) {
result: calc(var(--v1) + var(--v2));
}
.foo {
--v1: 1;
--v2: 2;
z-index: --outer();
}Under the current specced behavior, the z-index is 210 - Under the alternative I describe above, the z-index is 12 - @andruud, any thoughts? |
I agree that we should, and there are several open issues to do so. However, even if we solve it for the common case, I think there will always be use cases where you want to pull in multiple properties with a shared prefix.
Or we define that the using lists of each function are separate, a function calling another function doesn't need to specify a superset of using for the child call to work. It’s harder to implement, but much better ergonomics IMO.
Agreed. One solution could be to simply not allow that, specify that you need at least one character.
I had assumed a function’s parameters shadow any custom properties in
I like that. |
|
Wouldn't CSS Variable Groups (#9992) be a viable solution? |
I'm not sure we should have
That problem exists because we have
|
|
Agreed with @andruud that What if variable references that the function is not able to resolve are propagated and resolve at the point of calling? Would something like that work? |
Both of these mean that functions can have arguments that one calling context is allowed to control (the element itself), but all other contexts can't. If you write a function that calls other functions, the "global" variables they're grabbing simply bypass you entirely. Neither of them fix the "dynamic scoping" aspect of the concept, they just make that scoping even less controllable. I'm not sure why we'd want that. The point of Like, check out my Bikeshed usage of Looked at another way, this is just carrying the custom property inheritance behavior from elements into functions. We already recognize that being able to override a custom property on an entire subtree by changing it on the common ancestor is useful; it would be quite bad if every single element in the subtree had to manually indicate it was inheriting all the custom properties its descendants were using. The point of adding I am opposed to (a) not exposing element variables at all, so arg lists have to be enormous and coordinated, or (b) exposing specifically element variables, in a way that can't be overridden at the call site, as it means inlining a function can change its behavior. Maintaining beta reduction is important, I think. |
If I'm understanding this correctly, this is what I just suggested with "remove |
I think so, yes. I think that makes a lot more sense. Q: It would be nice if there was a JS API to add pure computational functions to CSS down the line. Would this preclude such an API? |
Not necessarily. It just means that, rather than declaring which vars you want, and being given an object containing just them, we'd have to give you an object containing every visible var. |
|
I like the proposal to remove |
That is "full" dynamic scoping, then. If that's indeed what we want, well OK. But should mention a good point (made elsewhere) by @mgiuca, that dynamic scoping breeds chaos for closures/higher-order functions. (Imagine passing a function around in a value and have that behave differently depending on where it's invoked.) So I think a resolution to do dynamic scoping, is also a resolution to never do closures or similar in CSS. (That might be OK.) |
|
That makes sense. I wonder if people have use-cases in mind for that. |
|
Dynamic scoping is how CSS variables generally behave though, so it seems like that ship has sailed? |
|
I don't think what we decide here has any relevance for closures later, actually. Functions as we're defining them simply do not have a meaningful lexical scope - they're defined at the stylesheet level, which doesn't contain anything except global state; importantly it doesn't contain any custom properties. So all non-global references must be either lexical from arguments, or dynamic from the calling environment (the element the value is being set on); that's the only choice. If we ever introduced closures (property-level function definitions, rather than global), we could, if we chose, distinguish between lexical variables (drawn from the element the function was defined on) and dynamic (drawn from the element the function is executed on). I imagine we'd reuse this |
usingis a great first step, but in practice if you actually need access to design system variablesusingwill get extremely unwieldy.For example, this is what it would look like if you want access to Open Props colors:
It gets even worse if you want access to other tokens too.
With wildcards, it would become the much more manageable:
And for many other design systems that use some kind of prefix for all colors (e.g.
--wa-color-*), it would be even simpler.It would even allow passing all custom properties, by simply doing
--*.The text was updated successfully, but these errors were encountered: