- From: Brandon McConnell via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Oct 2022 23:51:26 +0000
- To: public-css-archive@w3.org
I opened a [nearly identical issue](https://github.com/w3c/csswg-drafts/issues/7881) to this earlier today that thankfully, @Loirooriol caught before I went too far down that rabbit hole. Originally, I started with the function name, `fallback()` which admittedly sounds kinda boilerplate-y as far as names are concerned. I chatted with @joshvickerson about this idea [on Twitter](https://twitter.com/branmcconnell/status/1580667272951390208), and he [proposed the function name](https://twitter.com/joshvickerson/status/1580656929705426944) `prefer()` which I highly…"prefer" 😅🤦🏻♂️… to ~`fallback()`~, so my vote would be for that name if we're still bikeshedding on it. Re the functionality, the functionality is nearly identical but likely not 100% the same. Specifically in regarding to `var()`, my suggestion is generally that `var()` rather than always assuming a truthy eval would actually use the value of the `var()` in real-time, so something like this (below) would work as expected and not simply eval to the first `var()` as would normally happen in the cascade. ```css element { color: prefer(var(--property-1), var(--property-2), var(--property-3), color(display-p3 1 0 0.87), black); } ``` This is something I advised against in my original spec proposal, but @Loirooriol very correctly pointed out that simply using identifiers (e.g. `--property`) without `var()` could easily be confused with other identifiers, such as counters which can use a similar naming convention. So my new stance would be to enforce using the `var()` function within `prefer()` but allow for them to eval to false even without a falsy fallback value. I think this proposed spec and the one I posted share the same syntax, essentially this: ```css prefer(value1 [, value2?, value3?, ..., valueN?]) ``` -- GitHub Notification of comment by brandonmcconnell Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5055#issuecomment-1278293274 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 October 2022 23:51:28 UTC