[css-values-5] we should ensure an if with no fallback can be reasoned about later

[keithamus]

/If the if conditionals (https://github.com/w3c/csswg-drafts/issues/10064) have an open question as to whether a condition without a valid fallback should be empty token stream or IACTV. I believe we should consider how these can compose and how user can reason about whether or not the condition resolved to one-or-the-other where possible. Some contrives examples:

--my-hue: if(style(max-width: 400px): 300);
background: oklch(70% 0.1 var(--my-hue, 0)) /* This should fallback to zero */

--my-lch: if(style(max-width: 400px): 300);
--my-keyword: if(style(max-width: 500px): red);

background: if(
  var(--my-keyword): var(--my-keyword); /* when 500px this should resolve to `red` */
  else: oklch(70% 0.1 var(--my-hue, 0)); /* otherwise we might have an okclh hue */
); // This should be `red` or `oklch`

I'm unsure if IACTV vs empty token stream precludes conditions such as these but I think if they do that should be a deciding factor,

[LeaVerou]

@keithamus I don't understand the second example, I think there may be a typo there? The first one won't work with the current behavior, but that’s a bit of a special case (empty values are valid in custom properties). For non-custom properties, if their whole value is if() they would become IACVT if nothing matches. However, in the general case, an empty token stream is more composable, as you can have multiple sequential if() that are independent and compose a value, whereas if a single if() makes the whole declaration IACVT, that limits what you can do.

I suspect your first example can be rewritten, but without a real-world use case it's hard to suggest how.

[keithamus]

I think they could both be rewritten to avoid if/else but I was trying to demonstrate a property of the if result is that it should be introspectable in subsequent ifs.