Adds a style() function to @container rules to make it possible to apply styles based on the computed values of custom properties of an ancestor element. style() queries can be combined with size container queries which shipped in M105.
None of the other vendors have responded to the standards-positions or, to my knowledge, started implementing. There were concerns raised by an Apple engineer in https://github.com/w3c/csswg-drafts/issues/7185 mainly for standard property queries. This intent is for shipping support for custom property queries only.
Feature detection is not very ergonomic before we add at-prelude testing to @supports, which requires a resolution for [1]. [1] https://github.com/w3c/csswg-drafts/issues/6966
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
DevTools may need to show style containers like it is done with size container queries today. However, all elements are style containers by default, so probably not the same type of UI. There is an issue where we look up the wrong container, that is, always assume that the closest container supporting logical inline axis queries is the closest one: https://crbug.com/1378237 If we fix that issue, we will automatically also implement correct container lookup for pure style containers. That should work both for highlighting elements querying a given container, and also list the query for the matched style rule correctly.
DevTrial on desktop | 107 |
DevTrial on Android | 107 |
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeSQJOPtK%2BOmFj%2B7F%3DbCqqspoKshc7nDb0fh1BSoHmz95g%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY99fxZDTbmkTYdZ7Z8p9F-UxoczLaGsZMvmP2J2p6mUBA%40mail.gmail.com.
LGTM1For other reviewers, I verified these tests are all passing 100% (thank you Rune!):https://wpt.fyi/css/css-contain/container-queries/custom-property-style-queries.html https://wpt.fyi/css/css-contain/container-queries/custom-property-style-query-change.html https://wpt.fyi/css/css-contain/container-queries/at-container-parsing.html https://wpt.fyi/css/css-contain/container-queries/at-container-style-serialization.html
Debuggability
DevTools may need to show style containers like it is done with size container queries today. However, all elements are style containers by default, so probably not the same type of UI. There is an issue where we look up the wrong container, that is, always assume that the closest container supporting logical inline axis queries is the closest one: https://crbug.com/1378237 If we fix that issue, we will automatically also implement correct container lookup for pure style containers. That should work both for highlighting elements querying a given container, and also list the query for the matched style rule correctly.