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? 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 (--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.) >> >> > 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 >> >> 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 >> >> <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/602a7e34-4670-4b58-9281-219636998bf8n%40chromium.org.