Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/w3c/csswg-drafts/issues/11500 below:

[css-values] Short-circuit if() evaluation · Issue #11500 · w3c/csswg-drafts · GitHub

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()).

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3