Re: [csswg-drafts] [css-values-4] Allow an inline way to do "first value that's supported" (#5055)

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