Intent to Ship: Type-agnostic var() fallback
Anders Hartvoll Ruud
Contact emails
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 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 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
Search tags
custom properties, @property, var(), 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.
@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.
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.
@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), 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?
Yes
(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
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.
Mike Taylor
Could you please request the privacy, security, enterprise, etc
bits in your chromestatus entry?
--
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+...@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.
Anders Hartvoll Ruud
Could you please request the privacy, security, enterprise, etc bits in your chromestatus entry?
Alex Russell
LGTM1 contingent on that.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Anders Hartvoll Ruud
Hey Anders,I deeply appreciate the work you did to investigate the incompatibilities you found.
Dan noted that we hadn't filed for signals with the other engines directly. Can you do that?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Daniel Bratell
LGTM2
/Daniel
Mike Taylor
LGTM3 - thanks for filing the issues.