On Mon, Mar 17, 2025 at 7:18 PM Alex Russell
<slightly...@chromium.org> wrote:
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?
I intentionally didn't, since this is essentially a bug fix with clear
alignment, but very well:
WebKit: https://github.com/WebKit/standards-positions/issues/472
Gecko: Not filing a request, as they already fixed it
<https://bugzilla.mozilla.org/show_bug.cgi?id=1952516> during this intent.
LGTM1 contingent on that.
Best,
Alex
On Tuesday, March 11, 2025 at 3:20:38 AM UTC-7 Anders Hartvoll
Ruud wrote:
On Mon, Mar 10, 2025 at 8:37 PM Mike Taylor
<miketa...@chromium.org> wrote:
Could you please request the privacy, security,
enterprise, etc bits in your chromestatus entry?
Ah, yes. Done.
On 3/7/25 7:31 AM, Anders Hartvoll Ruud wrote:
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.)
Filed a PR for this, and pinged representatives from the other
vendors: https://github.com/w3c/css-houdini-drafts/pull/1139
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>.
--
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/CAKFBnUrHaRXAemQsfspRq0odmn63hMA9Uk5x%3D3u%3D9hbjY3Xi3w%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUrHaRXAemQsfspRq0odmn63hMA9Uk5x%3D3u%3D9hbjY3Xi3w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
