I did some tests with the way custom properties (unregistered, and registered as inheritable and non-inheritable) interact with the CSS-wide keywords, and I found a few issues in Safari and Firefox (Chrome rendering everything as I expected). I am filling one bug for all the WebKit issues, but feel free to separate those into sub-bugs if you need to. I also did open a WPT PR adding all my tests there — https://github.com/web-platform-tests/wpt/pull/46814 — so the code in that PR (or in WPT when it will be merged) can be used to reproduce all these issues. There is also a CodePen where I initially tested this, which can also be used to reproduce the issues — https://codepen.io/kizu/pen/rNgpXwL Here is a list of issues I saw in my testing in Safari Technology Preview (Release 196 (Safari 17.4, WebKit 19619.1.16.3), 8 failing out of 30 cases): 1. `revert-layer` does not work when used as the value of a non-registered custom property. This is the only bug I found an existing bug for: https://bugs.webkit.org/show_bug.cgi?id=271136 2. `revert-layer` does not work when used as the value for a registered custom property with `inherits: false` — WebKit uses its `initial-value` instead of the proper value from the cascade. Interestingly, it works fine when used with `inherits: true`. 3. Almost the same as previous, but when used as the fallback value for a custom property (like `var(--foo, revert-layer)`), again, when `inherits: false`. 4. WebKit seems to fail with unregistered custom properties when any of the CSS-wide keywords are used as the fallbacks (5 failing cases). I found two existing WPT tests that fail for some of these: https://wpt.fyi/results/css/css-variables/wide-keyword-fallback-002.html?label=master&label=experimental&aligned&q=wide-keyword and https://wpt.fyi/results/css/css-variables/revert-layer-in-fallback.html?label=master&label=experimental&aligned&q=revert-layer, but decided to still add those in my WPT PR so we will have all the similar cases in one place. Main spec we are working with is the css-variables one, specifically in places where it defines how custom properties should interact with CSS-wide keywords: https://drafts.csswg.org/css-variables/#ref-for-css-wide-keywords%E2%91%A0 (see also other places in the same spec searching in-page for “css-wide”). In short, those CSS-wide keywords should work with the custom properties exactly like with regular properties: > The CSS-wide keywords can be used in custom properties, with the same meaning as in any another property. > > > Note: That is, they’re interpreted at cascaded-value time as normal, and are not preserved as the custom property’s value, and thus are not substituted in by the corresponding variable. and > If a declaration, once all var() functions are substituted in, contains only a CSS-wide keyword (and possibly whitespace), its value is determined as if that keyword were its specified value all along. > > Example 14: While a var() function can’t get a CSS-wide keyword from the custom property itself—if you tried to specify that, like --foo: initial;, it would just trigger explicit defaulting for the custom property—it can have a CSS-wide keyword in its fallback
<rdar://problem/130526334>