[css-contain] Is there a use-case for querying explicit container selectors?

[mirisuzanne]

@dbaron's original proposal included an explicit selector for the container to be queried:

@container <selector> (<container-media-query>)? {
  // ... rules ...
}

In part, that's explained as a way to implement scope as part of containment. But I'm not sure those two features always make sense together, and all the CQ use-cases I've encountered so far rely on:

• Querying the most immediate available space
• Being able to move components between containers

Requiring an explicit selector would make those use-cases more difficult, since it makes the query less modular, and potentially less relevant to immediate context. That said, if the selector is useful in some cases, we could consider allowing it as an optional syntax:

@container (<selector>)? (<container-media-query>)? {
  // ... rules ...
}

Aside:

• I imagine it only works when the selectors inside the query are descendants of the container selector.
• What if a selector is provided without any other query conditions? Is that allowed? It starts to look a lot like scope…

I can imagine some hypothetical use-cases, though most would be solved by using descendant selectors (or @scope) along with container queries. In those cases it might be syntax sugar, but doesn't provide much. More important would be any use-cases where an author wants to "skip over" the most immediate container context, and query a container farther up in the DOM tree. Do those use-cases exist?

[kizu]

More important would be any use-cases where an author wants to "skip over" the most immediate container context, and query a container farther up in the DOM tree. Do those use-cases exist?

I can't remember the exact use-cases for this, but given there were tons of these in my practice for skipping the stacking context etc, I'm pretty certain there would be use-cases for this (I'll try to remember/come up with such` use-cases if I'll have time).

As a quick idea — I imagine most of such use-cases could be whenever we have something that escapes its own scope, but need to also need the grandparent's scope as well. Think of a content column, where something wants to escape the content grid and stretch among the whole width of the page — it would make sense to make the content column a container, so everything inside would scale properly, but then we wouldn't be able to make a child wider than that container, and at the same time to know the upper boundaries. (I can illustrate this example if I couldn't describe it properly, let me know!)

Said that, the universal “nearest” container is a really nice default, as in most cases we'd want for our components to just work and adjust to the nearest container. However, for more complex scenarios we would want to skip some levels of containment when we know the selector of the thing we want to rely on.

(Another possible case: #6177 — it could benefit from the targeted containment (I'll try to describe how in that PR). — edit: after thinking a bit more about how the nested containment and a potentially explicit containment could work, I'm not sure what I had in mind applies to that PR, so nevermind on this issue)

[SebastianZ]

If explicit container selectors are a thing, in my opinion, the syntax should be a little different than the one you proposed, @mirisuzanne. The syntax you suggested surrounds the selector with brackets. This kind of syntax is only used for the conditions in media queries so far.

One solution would be to just write the selector without brackets, i.e. <selector>?. Though in regard of #5811 and to make the syntax future-proof for possible extensions, the selector should probably rather be defined as a function.

Sebastian

[mbacon-edocs]

RE: use cases, the main one I'm thinking of that makes me hope this gets supported is this (although really this would call for immediate parent selector, perhaps just * as the selector would work) - having to predefine a parent element as a container can create problems with component based development, if I want to style the component and have it react to wherever it's being used, you have to break the components concept to 'prep' the parent elements - granted this could be done with JS auto-modifying the parent, but would be nice if CSS handled this use case

[mirisuzanne]

@mbacon-edocs I don't think it's possible that we would allow queries to create containers. You will always need both. But the author does still have options. Components can "carry their own container" as a wrapping element. But I also think it's totally reasonable to think of "containers" as a layout concern (not attached to the component), and "queries" as a component concern (responding to space available in the layout). Queries are about responding to context, after all.

I do think there are several reasons we do want to allow specifying the container still:

• I originally assumed the queries would only match against containers with the necessary containment, but that doesn't seem like a good plan ([css-contain-3] What happens when the queried dimension is not contained by the nearest container? #6303) which means you may want to skip over the nearest container, to query one with more appropriate containment.
• If we allow different types of query, in addition to dimensional queries, that need becomes even more likely. With dimensions you often want to know the most immediate context, but with states & styles, that becomes less clear.

In working on a more explicit syntax for containment, I also proposed a custom-ident syntax for this — allowing authors to name their containers in a more flexible way, and then refer to those names from the query. I think that provides a simpler syntax here (we don't have to handle complex selectors), while also making it possible to set up naming conventions. You could have, for example, containers named layout and containers named for their individual components, and explicitly decide when to query external or internal context… without hard-coding the selectors in the query:

main {
  container-type: inline-size style;
  container-name:  layout-area;
}

@container layout-area (inline-size > 30em) { … }

[mbacon-edocs]

@mirisuzanne Yes of course, I was concerned about having to define containers around all components in case they wanted to use container queries, but you're right, they'll have to just have a wrapping element to be defined as one which should fix it.

Also on the topic of selector(s), my 2 cents, I think having it optional (specific when defined, or undefined means nearest parent container) would be best. I also like the naming concept (whether enforced or optional vs typical selectors) as it feels in keeping with the concepts in CSS grid areas.