LGTM3; +1 to Yoav's thanks re: the thorough analysis. On Wednesday, May 7, 2025 at 7:59:03 AM UTC-7 Yoav Weiss wrote:
> LGTM2 > > Thank you for the thorough analysis!! Let's break this vicious cycle! > (before it's too late) > > On Wednesday, May 7, 2025 at 4:38:43 PM UTC+2 Daniel Bratell wrote: > > LGTM1 > > And now I've learned about impossible things you can (or could) do with > CSS. I'm not sure that was a good thing. > > /Daniel > On 2025-05-07 11:12, Anders Hartvoll Ruud wrote: > > 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). > > Can you expand on what you mean by the substack.com case? Are these all > embedding a single 3P? > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUoscDWjNm%2Bk9v6_dNF%3D82XxBkamBJAFyEhh%2BZEU-JJ32g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- 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/1d53d375-34cc-45ba-a7c3-090f9cb0cd8an%40chromium.org.
