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 (--lengthis 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
<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
<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 inheritkeyword 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-controlleron 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 --textas 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
colorof 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
<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
<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
<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
<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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUpT2WdeByfYYaDG45Pq%2BWQMcK-NL81fQqscZwQrj%3DxeCQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
