Contact emails andr...@chromium.org
Explainer When designing the if() <https://drafts.csswg.org/css-values-5/#if-notation> function, we (CSSWG) decided to make it short-circuiting <https://github.com/w3c/csswg-drafts/issues/11500>, such that we can stop evaluation once a matching condition is found, for example: if(cheap-test1(): 10px; cheap-test2(): 42px; else: --expensive()) In the above, if cheap-test1() evaluates to “true” (let’s say), then we can avoid considering the cheap-test2() and “else” branches entirely, and avoid potentially expensive calculations that are not needed. For consistency, we resolved on doing this for all substitution functions. This affects three substitution functions which are already shipped: var(), attr(), and env(). For these functions (using var() as an example), there can at most be two “branches”: the main value branch, which fetches the value of a custom property, and the *fallback*: color: var(--my-color, black); In the above, color becomes whatever --my-color is. If --my-color does not exist, color becomes black (the fallback) instead. Today, we need to evaluate the contents of the fallback even when --my-color actually exists. This is because the spec requires us to look for cycles in that fallback: --green: green; --blue: blue; --a: var(--green, var(--b)); --b: var(--blue, var(--a)); Even if --green and --blue both exist, --a and --b end up invalid here. This is because a cycle exists via the fallbacks. This intent changes this: we now only care about the fallback when we’re actually using the fallback. Specification https://drafts.csswg.org/css-variables-1/#replace-a-var-function https://drafts.csswg.org/css-values-5/#cyclic-substitution-contexts Summary When the fallback is not taken, var()/attr() functions evaluate without looking for cycles in that fallback. Blink component Blink>CSS <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> TAG review None TAG review status Not applicable Risks Interoperability and Compatibility In theory, three functions are affected by this: var(), attr(), and env(). However, it turns out that env() already had the desired behavior in Blink, so we can disregard that. I have added use-counters for the two others: CSSVarFallbackCycle <https://chromestatus.com/metrics/feature/timeline/popularity/5334> - approximately 0.01% (of page views) CSSAttrFallbackCycle <https://chromestatus.com/metrics/feature/timeline/popularity/5335> - approximately 0% (of page views) The attr() function (in its current form) was shipped very recently, and we can discard this as well given the 0%. This leaves the var() function. The primary concern here stems from Roman’s terrible (but excellent) Indirect Cyclic Conditions: Prototyping Parametrized CSS Mixins <https://kizu.dev/indirect-cyclic-conditions/> technique, which relies on the current non-short-circuiting cycle detection behavior. If authors had actually started using this technique widely, then we would be stuck with the current behavior for var(). I investigated this more deeply using HTTP Archive: Short-circuiting var() & attr() compat investigation <https://docs.google.com/document/d/1qHOZr5PK9WQWZtPIQvmAqps74pyjMyZ7uOvqq6MxyZs/edit?usp=sharing> (summary below). Summary: I queried HTTP Archive using the recommended methods, and found 70655 pages triggering the counter. 96% of these hits were confirmed to be the same case (the substack.com case). The impact of this intent on that case seems to be somewhere between “zero and cosmetic”. In fact, ~all the cases seem to follow a pattern of --x:var(--reasonable-value, --x) (i.e. using yourself as the fallback), which means this intent now just yields --reasonable-value instead of “invalid”. An exception to this is four URLs from kizu.dev (Roman’s blog), which clearly stand out in the data. However, Roman (“kizu”) actively participated <https://github.com/w3c/csswg-drafts/issues/11500#issuecomment-2669358882> in the decision to change the behavior, and ultimately agreed to it. Gecko: No signal (recently filed) https://github.com/mozilla/standards-positions/issues/1224 WebKit: No signal (recently filed) https://github.com/WebKit/standards-positions/issues/489 Web developers: No signals Other signals: WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? None Debuggability Not affected. It’s as debuggable as before. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? Yes Flag name on about://flags None Finch feature name CSSShortCircuitVarAttr Rollout plan Will ship enabled for all users Requires code in //chrome? False Estimated milestones Shipping on desktop 139 Shipping on Android 139 Shipping on WebView 139 Anticipated spec changes None Link to entry on the Chrome Platform Status https://chromestatus.com/feature/6212939656462336?gate=5113879470014464 This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUoscDWjNm%2Bk9v6_dNF%3D82XxBkamBJAFyEhh%2BZEU-JJ32g%40mail.gmail.com.
