Created attachment 470261 [details] Screenshot of the test case from Safari TP Steps to reproduce: 1. Go to https://codepen.io/kizu/pen/poBgBMb in Safari TP and Chrome and compare how things render. 2. There is a difference in how Safari and Chrome treat the `initial` in the container style query. It seems that Safari treats the `initial` in style queries for custom properties when it is an _implicit_ value (never explicitly set to `initial`) and when it is explicitly `--foo: initial` differently. In the example above, uncommenting the `--is-lightgreen: initial;` on the root also leads to the difference.
I am able to reproduce this bug on WebKit ToT (275874@main) where the `Checking for initial` does not match `Checking for space` compared to Chrome Canary 124.
Created attachment 470335 [details] rendering in safari, firefox, chrome Safari Technology Preview 190 19619.1.5.5.2 Firefox Nightly 125.0a1 12524.3.12 Google Chrome Canary 124.0.6354.0 6354.0
<rdar://problem/124573975>
I did open a PR adding WPT tests for this case: https://github.com/web-platform-tests/wpt/pull/45759
So --foo: initial computes to "guaranteed-invalid value" (https://drafts.csswg.org/css-variables-2/#guaranteed-invalid). The container query spec says (https://drafts.csswg.org/css-contain-3/#style-container). "Its query evaluates to true if the computed value of the given property on the query container matches the given value (which is also computed with respect to the query container), and false otherwise." It seems reasonable that two guaranteed-invalid values "match" but it is not really specified. It might be good to also file a CSSWG issue to clarify this.
Pull request: https://github.com/WebKit/WebKit/pull/27438
Thanks for the WPT, I also reviewed it.
Committed 277670@main (b5ce791faf9e): <https://commits.webkit.org/277670@main> Reviewed commits have been landed. Closing PR #27438 and removing active labels.