- From: Martin via GitHub <noreply@w3.org>
- Date: Mon, 09 Mar 2026 08:45:22 +0000
- To: public-css-archive@w3.org
The CSS `@container` query mechanism (setting aside the proposed workings of the `.matchContainer()` scripting API for a moment) can match an element when one of its ancestors (the _container_) meets the query condition. The container *must* be an ancestor, it can not be the element itself, posing as its own container.
This is by design; otherwise you would be able to write cyclic query conditions and style rules:
```css
.thing {
container-name: the-thing-itself;
--matches: true;
}
@container the-thing-itself style(--matches: true) {
.thing {
--matches: false;
}
}
```
My understanding of the proposed `.matchContainer()` scripting API is, that it would behave exactly as its CSS counterpart. Nay, it *must* behave exactly so! Anything else would lead to great confusion and probably bugs. You could have some elements that are queried and styled via the CSS feature, and simultaneously have a programmatic query listener via `.matchContainer()` that observes the exact same query (for example to process the UI state further inside a React component which has some conditional behavior). Those two different ways to listen to the exact same query in the exact same DOM must match in the exact same way so the results are in sync. They must not differ.
There seems to be some confusion what role the `element` has in `element.matchContainer(...)` so let me try to clarify: the `element` is the descendant, not the container. An eligible container is searched in the ancestor chain of that element; when a container is found that is eligible (its container-type corresponds to the query type, container-name matches if one is required by the query) the condition is checked, and if met, the query reports `matches` as `true`. This means `element` is currently in a container that fulfills the query condition.
@jamesnw My polyfill does not enforce or assume any _descendant_ and _ancestor_ relationship for the watched element; so for the unlikely case that one day a container query type should be added to the CSS standard that would allow an element to form its own container, then this should just work fine through the polyfill.
You contributed a testcase to the polyfill recently; so I believe I know your use case for needing to match an `anchored` query for a custom styled `<select>` element. You don't need to pick the first `<option>` to get a reference to a descendant, you can use the _dropdown_ element itself and it doesn't feel hacky anymore.
```html
<select>
<button>
<div>
<selectedcontent> </selectedcontent>
</div>
</button>
<div class="dropdown">
<option value="carrot">Captain Carrot</option>
<option value="garlick">Magrat Garlick</option>
<option value="dibbler">Cut-Me-Own-Throat Dibbler</option>
</div>
</select>
```
```js
const watchingEl = document.querySelector('.dropdown');
watchingEl.matchContainer(...
```
--
GitHub Notification of comment by teetotum
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6205#issuecomment-4022106222 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 9 March 2026 08:45:23 UTC