[css-values-5] Forwards compatibility for inline `if()`

[andruud]

Regardless of the outcome of #10064, should we implement something like <general-enclosed> for forwards compat?

For example:

background: if(
    future-thing(...): blue,
    style(--status:error): red,
    style(--status:warning): yellow,
    else: green
);

In the above, we probably want future-thing(...) to evaluate to false, rather than making the whole if invalid?

@LeaVerou @tabatkins

[LeaVerou]

This sounds like a great idea. In fact, what is the widest set of parse-able tokens we could allow there and simply have them evaluate to false? Does it change based on whether we use : or ? as the condition terminating token?

[andruud]

For comma/else, I think pretty much any comma/semicolon-separated item matching <declaration-value> ':' <declaration-value>? could be valid?

For :?, I guess it's <declaration-value> '?' <declaration-value>? for :-separated items?

[tabatkins]

While a <declaration-value> that excludes top-level : tokens is grammatically okay (that chunk of syntax is language-defined, so we're not applying restrictions to broader CSS development by adding that exclusion), it's not a good idea. The proposal was to use the <boolean> production that's already shared by MQs, SQs, and CQs, precisely so we could get general-enclosed and give it a truth value.

I think it needs to use the 3-value syntax like MQs, tho - if the UA doesn't understand the condition, it doesn't know whether the condition is true or false, so it shouldn't treat not gibberish() as true. (As opposed to an SQ, where unknown things are by definition false most of the time.)

[tabatkins]

With the addition of <boolean[]>, if() is now well-defined in this regard, so I'm closing this issue as handled.