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 (--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/CAKFBnUrHaRXAemQsfspRq0odmn63hMA9Uk5x%3D3u%3D9hbjY3Xi3w%40mail.gmail.com.
