[css-values][css-variables][css-mixins] Generic fallback syntax for IACVT values

[LeaVerou]

With variables, you can write components that can be customized externally by doing things like:

--_primary-color: var(--primary-color, oklch(...));

There should be a similar way to specify fallbacks for functions too. That way, people could e.g. define a function for all tints of a given color (e.g. --color-green(20) for a light green), and other code could try that first and provide a fallback light green if not specified.

However, rather than specifying a function or mixin specific syntax, I think we should really specify a generic fallback syntax for anything IACVT. Rationale:

• These cases are going to keep coming up, and unlike var(), there is no clear syntactic fit for a function call fallback.
• Furthermore, even with variables there are cases where providing a fallback is painful. E.g. consider something like oklch(90% 40% var(--hue)). To provide e.g. a medium gray as a fallback to the whole color (rather than just a fallback for --hue), you need to introduce an intermediate variable. Same for calc().
• A generic fallback syntax could also simplify attr(), which currently has its own separate fallback.

In terms of syntax, I see two options:

• A new function, e.g. fallback(<declaration-value> [ ; | , ] <declaration-value>). Main downside is verbosity.
• "Upgrading" var() to accept arbitrary values in the first argument — probably not a good idea, as it would be impossible to disambiguate variable references from <dashed-ident> keywords.

[Loirooriol]

I assume fallback() would need to be a <whole-value>?

Or would you initially treat all fallback() in the declaration as their 1st <declaration-value>, and if the property would be IACVT, treat all of them as their 2nd <declaration-value>?

[LeaVerou]

I assume fallback() would need to be a <whole-value>?

No, for this to work reasonably well, it would need to be allowed anywhere var() is. Otherwise the DX is very similar to assigning the value to a custom property and using a var() fallback for that.

Or would you initially treat all fallback() in the declaration as their 1st <declaration-value>, and if the property would be IACVT, treat all of them as their 2nd <declaration-value>?

Yup, by definition.

[tabatkins]

That way, people could e.g. define a function for all tints of a given color (e.g. --color-green(20) for a light green), and other code could try that first and provide a fallback light green if not specified.

I'm not sure I understand the request here. Is it to have the ability to do something different when the --color-green() function isn't defined?

[andruud]

@tabatkins Functions don't have a way to provide a fallback value (yet?) at the call site, for cases where they don't return a value (or don't exist). Like I said in #10562 (comment), we can do it with indirection via a custom property, but it's not very ergonomic. Something like fallback(--mayberesult(), 42px) could be better.