[csswg-drafts] [css-values] Short-circuit if() evaluation (#11500)

andruud has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-values] Short-circuit if() evaluation ==
In a world where huge trees of custom function calls and inline if()s need to be evaluated, it would be nice if we could stop evaluating once a matching condition is found:

```
 if(cheap-test1(): 10px;
    cheap-test2(): 42px;
    else: --expensive())
```

In the above, we don't want to evaluate (substitute) `--expensive()` if an earlier branch will do.

Relatedly, a `var()` function also has up to two branches: the main value produced by the custom property being referenced, and optionally the fallback value. As specified currently, we can _not_ short-circuit this "evaluation", since we need to look for cycles in the fallback value:

```
--valid: 1px;
--x: var(--valid, var(--y)); /* Cycle; IACVT */
--y: var(--valid, var(--x)); /* Cycle; IACVT */
```

`--x` and `--y` are in a cycle above, even though the fallback paths are not taken. By default, I'd expect this to extend to the branches not taken for `if()` as well, otherwise we'd miss the cycle in a case like:

```
--x: if(test-which-is-true(): 10px;
        else: var(--y));
--y: var(--x);
```

So:

- Should we specify this short-circuiting behavior for `if()`?
- Should we avoid looking for cycles in the fallback part of `var()` when it's _not_ taken? (Requires compat investigation.)
- Should we generally avoid looking for cycles in a branch not taken during any substitution? (E.g. `attr()`).

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11500 using your GitHub account


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

Received on Tuesday, 14 January 2025 17:48:49 UTC