[css-values-4] Allow an inline way to do "first value that's supported"

[tabatkins]

When authors use var(), the UA has to assume that the property value is valid at parse time, and only check at computed-value time. If it ends up not being valid, it becomes invalid-at-computed-value-time, reverting to either initial or inherit.

This, unfortunately, loses us CSS's very useful forward-compatibility feature, where we can specify a property two or more times with different features and get the last one the UA supports. Instead we get the last one the UA supports or that has a var() in it, even if the var()-containing one uses features the UA ends up not understanding!

Making this worse, more features are ending up requiring var()-like parsing - attr(), custom functions, etc - so this will only get more common. It would be pretty unfortunate to lose the forward-compatibility feature for a large swathe of CSS usage.

An author can, of course, work around this with @supports. Unfortunately, it has the same separation/repetition/verbosity issues as MQs do, as explained in #5009.

So, related to #5009, perhaps we could have a "validity switch" in the same way? It'd be one of those "must be the whole value of the property" things, and using the same fallback logic as normal CSS, it would resolve to the last item the UA understands. It would just do it at computed-value time, so post-substitution.

So something like:

:root {
  --fg: last-supported(blue; lch(30% 130 300));
}
.foo {
  color: var(--fg);
}

[Loirooriol]

In var() the fallback value is the 2nd argument. So for consistency this seems more natural to me:

:root {
  --fg: first-supported(lch(30% 130 300); blue);
}

[Loirooriol]

It could be good to accept a CSS-wide keywords, e.g.

display: first-supported(foo; bar; revert);

if neither foo nor bar are supported, it would behave as revert, preserving UA styles. Without revert I guess it would just become invalid at computed-value time and behave as unset.

[andruud]

CSS-wide keywords need to be the cascaded value, which they won't be in this case. So putting CSS-wide keywords in such a function doesn't work with the current model.

Not saying it's impossible, and we're already effectively reverting at computed-value time (#4155), so perhaps we should go all-in and generalize to all CSS-wide keywords and spec it properly. :P

EDIT (one year later): Since my original comment we have allowed CSS-wide keywords in var() fallbacks, so first-supported(foo; bar; revert) is now totally in line with what already exists.

[FremyCompany]

Strong +1

I have proposed first-of(...) back a long time already, and I think this would make many things much better!

[LeaVerou]

It'd be one of those "must be the whole value of the property" things

Are there others?

[tabatkins]

toggle(), and now mix()

[Loirooriol]

• What happens if it's mixed with other things?

  :root { --fg: first-supported(grid; flow); }
  .foo { display: var(--fg) list-item; }

  display: grid list-item is currently invalid, and display: flow list-item is valid, so would it pick flow?

  Or the top post says "must be the whole value of the property", does that mean invalid at computed-value time otherwise?

• When does it resolve?

  If the usecase is using first-supported() in a variable, and then resolving depending on which property the variable is used, then it must stay unresolved in the variable.

  But what if used in a standard property like display: first-supported(foo, grid)? Does it resolve immediately at parse time? At computed-value time? What about registered custom properties?

• What if all values are invalid?

  :root { --fg: first-supported(foo; bar); }
  .foo { display: var(--fg, grid); }

  Does display become invalid at computed-value time? Does it fallback to grid?

  .foo { display: grid; display: first-supported(foo; bar); }

  If it's resolved at parse time in standard properties, and all specified values are invalid, is the declaration dropped, producing display: grid? Or display becomes invalid at computed-value time?

• What if some value contains var()?

  .foo { display: first-supported(var(--foo); grid); }

  Does it behave like display: var(--foo) since that's valid syntax (like in @supports), or would it wait to substitute the variable before checking the validity (like usual for var())?

  Top post says both "using the same fallback logic as normal CSS" and "post-substitution", so not clear.

[tabatkins]

What happens if it's mixed with other things?

Parse failure.

(In your example, it's fine in the custom property, because the custom property doesn't see a first-supported() function, it sees a sequence of tokens. Once substituted and given meaning, it's now not the sole value in a property, and thus is a parse failure (thus IACVT).

When does it resolve?

Parse time. This is a pure functionality substitution for just writing the property twice and using the last one that parses.

(As stated above, it's not resolved in a custom property, as only var() functions are. But once substituted, the late parse-time validation that can trigger IACVT takes over.)

What if all values are invalid?

Parse failure.

If it's resolved at parse time in standard properties, and all specified values are invalid, is the declaration dropped

Yes, since it's a parse failure. ^_^

What if some value contains var()?

Then it successfully parses (so long as the var() itself is valid), and is used. Again, pure substitution for "write it twice".