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 allsubstitution
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-coloris. If --my-colordoes
not exist, color becomes black(the fallback) instead.
Today, we need to evaluate the contents of the fallback even when
--my-coloractually 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 --greenand --blueboth exist, --aand --bend 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-variables-1/#replace-a-var-function>
https://drafts.csswg.org/css-values-5/#cyclic-substitution-contexts
<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 <http://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-valueinstead of “invalid”.
An exception to this is four URLs from kizu.dev <http://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
<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/0294635e-4559-4342-aa82-2f881a77a5be%40gmail.com.
