Contact emails
andr...@chromium.org
Explainer
A var() function can provide a fallback value, in case the referenced
custom property does not exist (or is invalid in some other way):
.component {
width: var(--component-width, 100px);
}
When custom properties are registered
<https://drafts.css-houdini.org/css-properties-values-api-1/#behavior-of-custom-properties>
with some type (e.g. with @property), the current behavior is to consider
the var() function invalid if the fallback does not match the type of the
property being referenced:
@property --length {
syntax: "<length>";
inherits: false;
initial-value: 0px;
}
.foo {
--length: 100px;
width: var(--length, 50px); /* Valid, width becomes '100px' */
}
.bar {
--length: 100px;
width: var(--length, auto); /* Invalid, width becomes 'unset' */
}
As you can see above, this type restriction even applies when the fallback
would not be used (--length is present and valid in both cases).
This behavior is now seen as a mistake by the CSSWG, and in 10455
<https://github.com/w3c/csswg-drafts/issues/10455> we resolved to change
it: the fallback is no longer validated against the type of the referenced
property (regardless of whether or not it's used):
.baz {
--length: 100px;
width: var(--length, auto); /* Now valid, width becomes '100px' */
}
.bax {
/* Also valid, regardless of --undefined's type. Width becomes 'auto'. */
width: var(--undefined, auto);
}
Specification
https://drafts.css-houdini.org/css-properties-values-api-1/#fallbacks-in-var-references
(This is the section that should be removed.)
Summary
The fallback part of a var() function does not validate against the type of
the custom property being referenced.
Blink component
Blink>CSS
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22>
Search tags
custom properties
<https://chromestatus.com/features#tags:custom%20propeties>, @property
<https://chromestatus.com/features#tags:@property>, var()
<https://chromestatus.com/features#tags:var()>, fallback
<https://chromestatus.com/features#tags:fallback>
TAG review
None
TAG review status
Pending
Risks
Interoperability and Compatibility
The use counter is at 0.000042%.
https://chromestatus.com/metrics/feature/timeline/popularity/5231
There are only four sites listed above, and I had a look at how this intent
would impact those sites. As far as I can tell, they are either not
affected, or now begin doing what they were actually intended to do.
https://athenabeachlagos.com/
@property --text-base {
syntax: "<color>";
inherits: true;
initial-value: #2A2A2A;
}
*, *:before, *:after {
color: var(--text-base, inherit);
}
With this intent, var(--text-base, inherit) is now valid even though the
inherit keyword is not a <color>. This causes the text on the page to
generally change from rgb(0, 0, 0) to rgb(42, 42, 42), which is probably
what was intended here anyway.
https://goodco.tv/
CSS.registerProperty:
--controls-backdrop-color {
inherits: true;
syntax: "<color>";
initial-value: rgba(0, 0, 0, 0.6);
}
.hide-controls mux-player {
--controls: none;
}
media-controller:is([media-paused],
:not([user-inactive]))::part(vertical-layer) {
background-color: var(--controls-backdrop-color, var(--controls, rgba(0,
0, 0, 0.6)));
}
The media-controller on this site seems to be hidden by default, with no
obvious way of enabling it. If I enable it with devtools, the controls
appear to have a fully transparent background. With this intent, it would
instead be the initial value rgba(0, 0, 0, 0.6), which seems harmless and
intended.
https://kvashmusic.com/
@property --bgrotate {
initial-value: 120deg;
inherits: false;
syntax: "<angle>";
}
@property --bgrotate2 {
initial-value: 255deg;
inherits: false;
syntax: "<angle>";
}
@property --text {
initial-value: 220deg;
inherits: false;
syntax: "<angle>"; /* <== Problem here */
}
label[_ngcontent-ng-c1815873975] {
background: var(--bg, white);
color: var(--text, black);
}
They appear to have mis-registered --text as an <angle>, perhaps because it
started as a copy-paste from --bgrotate1/2.
label[_ngcontent-ng-c1815873975] (despite being a <label>) is a theme
switcher widget, that by the looks of it will now get a computed color
of rgb(255,
255, 255) rather than rgb(51, 51, 51). This seems to not matter, since
there's no actual text in the element, nor anything appearing to use
currentColor. (This intent has no effect here.)
https://www.belabijuterias.com.br/
@property --rotate {
syntax: "<angle>";
initial-value: 132deg;
inherits: false;
}
.elementor-widget-text-path svg {
transform: rotate(var(--rotate,0)) scaleX(var(--scale-x,1))
scaleY(var(--scale-y,1));
}
Zero is apparently not a valid <angle> (spec
<https://drafts.csswg.org/css-values-3/#angles:~:text=NOTE%3A-,For%20legacy%20reasons%2C,-some%20uses%20of>),
hence var(--rotate,0) would previously be invalid.
This intent appears to have the effect of rotating a circular element on
the page, likely as originally intended.
(End of detailed compat investigation.)
Gecko: No signal
WebKit: No signal
Web developers: No signals
Other signals: I have not requested official signals (that is a lot of
paperwork for a small detail), but it's clear that the WG considers the
original behavior a mistake, with support from both fantasai (Apple) and
Emilio (Mozilla) in the meeting notes.
https://github.com/w3c/csswg-drafts/issues/10455#issuecomment-2402837489
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
None
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
https://wpt.fyi/results/css/css-properties-values-api/var-reference-registered-properties.html?label=master&label=experimental&aligned&q=var-reference-registered-properties.html
(The tests are currently testing the old behavior. They will be updated
when the main code change lands in Blink.)
Flag name on about://flags
None
Finch feature name
CSSTypeAgnosticVarFallback (not actually added yet)
Requires code in //chrome?
False
Tracking bug
https://issues.chromium.org/issues/372475301
Estimated milestones
Shipping on desktop
136
Shipping on Android
136
Shipping on WebView
136
Anticipated spec changes
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5128966769475584?gate=5169003917737984
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/CAKFBnUpT2WdeByfYYaDG45Pq%2BWQMcK-NL81fQqscZwQrj%3DxeCQ%40mail.gmail.com.
