- From: Miriam Suzanne via GitHub <sysbot+gh@w3.org>
- Date: Thu, 05 Jan 2023 18:57:48 +0000
- To: public-css-archive@w3.org
@anttijk The change we're making is only to the container-selecting logic. We're not changing how any of those situations resolve once a container is selected - so there's no parallel in media queries. Here's the text that needs to be changed: ``` For each element, the query container to be queried is selected from among the element’s ancestor query containers that are established as a valid query container for all the container features in the <container-query>. ``` I'll need to look up some terms to get the final language right, but roughly we want: - If the `<container-query>` includes `or` logic, a selected `container` only needs to be established as a valid query container for the features on _either side_ of the `or`, but not both sides. So a query like: ```css @container (height) or (width) { … } ``` Does not require an ancestor container that is established for *both* `height` and `width` queries, but can select and query a container that is established for *either* `height` or `width` queries. We may also want to clarify that: - If a container is selected that does not support all the features in a query, then the unsupported conditions resolve as `unknown`. By making those changes, we ensure that unsupported-features-on-a-container and general-enclosed provide similar results in a query. -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7551#issuecomment-1372610523 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 5 January 2023 18:57:50 UTC