Re: [csswg-drafts] [css-values-5] we should ensure an if with no fallback can be reasoned about later (#10956)

Agenda+ because, on review, this case isn't actually possible! [Earlier](https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2372578597), I thought you could just make one of the `if()` branches resolve to the guaranteed-invalid value and suggested, as an example, using an invalid `var()`. But that makes the whole property it's in invalid unconditionally (either at parse time, if it's grammatically invalid, or at substitution time, if it's cyclic or non-existent); it doesn't let you just get the invalidity in the one `if()` branch.

So, there's no way for an `if()` in a custom property, currently, to later be introspected for validity.

I can see two possible fixes:

1. We could add a test to `if()` for empty streams, like `if(empty(var(--foo)): ...)`, which is true if it's empty (importantly, after substitution). This would let you test for if an `if()` failed all its conditions.
2. We could finally add a reserved global keyword that is guaranteed-invalid. If we do this, I propose we spell it `guaranteed-invalid`, which is a bit past our normal spelling-complexity limits, but makes me laugh. Then, you could write `--foo: if(...; else: guaranteed-invalid)`, and then `var(--foo, 0)` will trigger fallback *if* the `if()` hit its `else` clause, because *at evaluation time* it resolved to the guaranteed-invalid value, which is what actually triggers fallback in var().

Possibly we should do both; testing if a variable is empty might be useful regardless, even if the emptiness came from something other than an `if()` that failed all its tests.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10956#issuecomment-2452730885 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 1 November 2024 23:52:12 UTC