- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Feb 2023 19:04:56 +0000
- To: public-css-archive@w3.org
I agree that there's a need for something in this vein, to allow storing arglists for functions like `random-item()` (and other semicolon-delimited lists) in a variable. Not a fan of exactly how it's proposed here, tho - it runs into some awkward grammar issues.
The core issue here is that a function can take `<any-value>`, while properties are limited to `<declaration-value>`. To store an `<any-value>` in a property, you need *something* to wrap it so it's not top-level; then you need some way to discard the wrapper when it's actually used (but not before then - if you sub a var() into another custom prop, it needs to retain the wrapper so the value remains valid).
So I think there are two possible approaches:
1. Define a function, call it `spread1()`, that is valid as a whole argument in `random-item()` and any other functions that accept anything broader than `<declaration-value>`. It has the grammar `spread(<any-value>)` (and thus can contain itself). Its only effect is to discard itself at computed-value time, lifting its own arguments into the parent function.
If used anywhere else it's just invalid syntax. Custom properties using `*` grammar can of course use it, since they just see a token stream rather than a function.
2. Define a function, call it `spread2()`, that isn't valid *anywhere* - only the `*` grammar can use it. It has special substitution behavior:
* if subbed into another `*` grammar, it subs as-is
* if subbed into anything else, it discards itself and leaves its argument behind.
The two are basically identical in usage:
```css
.foo {
--multiple-items: spread(1; 2; 3; 4; 5);
--single-item: 6;
some-prop: random-item(--x; var(--multiple-items); var(--single-item));
/* equivalent to */
some-prop: random-item(--x; 1; 2; 3; 4; 5; 6);
}
/* and nesting them works */
.foo {
--some-items: spread(1; 2; 3);
--more-items: spread(var(--some-items); 4; 5; 6);
--some-prop: random-item(--x; var(--more-items));
}
```
There are only meaningful difference between the two approaches is whether they're allowed in places that don't *require* them - `spread1()` isn't (it's defined to only be valid in the functions that need it) while `spread2()` is (can be used anywhere, but doesn't add any ability). Having the function be invalid where it's not needed (as in `spread1()`) might be good at discouraging confusing overuse, but having it be more explicitly tied to variable substitution (as in `spread2()`) might also be good for understanding. Really not sure which side I prefer.
--
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8391#issuecomment-1414225090 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 February 2023 19:04:58 UTC