[css-contain] Should there be a new syntax for establishing queryable containers?

[mirisuzanne]

In the current proposal for Container Queries, a container is any element with both layout and size containment. With the addition of 1D size containment (currently only inline), that can include size-containment in the axis being queried. At this point:

.container-2d { contain: layout size; }
.container-inline { contain: layout inline-size; }

If block-only containment is possible, that could expand to:

.container-block { contain: layout block-size; }
.container-width { contain: layout width; }
.container-height { contain: layout height; }

Once a container is established, it acts as a container-query target for descendants. That raises a few related questions:

1. Are there ever reasons to add layout and size containment, without establishing a new container context for descendant queries? (I don't believe that there is, based on my research so far. Authors generally want to query the closest context possible.)
2. Are there queryable features that would require a different set of containment values? For example, if we only want to query the value of custom properties, do we really need layout/size containment? (this depends a lot on what features we want to make queryable.)
3. Can we make it more clear or concise by adding explicit syntax for queries?

New syntax might help address any one or all of those cases, but each use-case might lead to slightly different solutions. This could happen with new values on the contain property, or with a new property (all names to-be-bikeshed):

/* keyword as shortcut for layout/size */
.container-2d { contain: query; }
.container-inline { contain: inline-query; }
.container-block { contain: block-query; }
.container-width { contain: width-query; }
.container-height { contain: height-query; }

/* new property, also triggers appropriate layout/size containment */
.container-2d { container: size; }
.container-inline { container: inline; }
.container-block { container: block; }
.container-width { container: width; }
.container-height { container: height; }

/* queries that don't rely on size containment?? */
.container { container: ???; }

[kizu]

I would say that I would welcome an explicit separate syntax for defining the containers that enable the queries, but the use-cases for this seem very close to #6176 — basically, I'm afraid of a situation where we add containment on an element for reasons other than querying, but end up changing the context for some of the children. Having these separate (but codependent?) would fix this.

[una]

Hi all, this is where I think an HTML element could help to differentiate the markup. In many instances with container queries, we need a wrapper element.

<container>
 <div class="child-i-want-to-style">...</div>
</container>

The reason I think introducing a new <container> element via markup could help is to avoid "divitis" and create a bit more clarity for the additional markup that container queries require. It breaks up what would otherwise be:

<div class="container">
  <div class="child-i-want-to-style">...</div>
</div>

And is more declarative in the type of containment, without looking up the CSS. This also prevents the requirement for managing classes like container-inline, container-2d, etc.

Attributes on <container>

We could also use attributes to specify the containment:

<container contain="inline">
 <div class="child-i-want-to-style">...</div>
</container>

Something like <container contain="inline"> or <container inline> would get default CSS values of:

contain: layout inline-size;

<container> by default would have some default styles which could be overridden like other HTML by applying CSS to it.

[eeeps]

It might be nice if any shorthand was explicit about the use case that it's solving:

contain: query-target;

I think I like the HTML option in addition to (but not in place of) a way to set query targets in CSS, though I would strongly prefer an attribute that could go on any element. So contain="inline|block" that could go on a <div> or an <article> or a <p> or whatever, but not a whole new <container> element that forces you to lose those other semantics and/or wrap things for styling purposes.

[mirisuzanne]

@una / @eeeps I think it the html element/attribute discussion likely deserves a separate issue – if one of you wants to open that? I think it's useful to consider, but doesn't directly impact the CSS syntax questions here.

I like the idea of being explicit (eg query-target) but we need a way to extend that out for different types of query-targets:

• to query both dimensions of the target: we need to apply layout, style, and 2d size containment
• to query one dimension: we need to apply layout, style and 1d (inline or block) size containment
• non-dimensional queries (being discussed in [css-contain-3] What container features can be queried? #5989) might have slightly different requirements (or might not require containment at all, just a syntax for establishing a target that can be queried)

I would hope that any solution we land on can be easily extended, as I expect there will be more interesting container queries down the road that we haven't considered yet.

[bramus]

Regarding the suggested new property option (i.e. container: size;) it's noted that it “also triggers appropriate layout/size containment”.

Although logical at first sight, this feels a bit weird when compared to how other CSS properties behave. For example, if I set place-items: center; on an element, it doesn't automagically trigger display: grid; along with that. Therefore I also wouldn't expect it to be the case here.

Given that, I'm more leaning towards the new keyword(s) which act as shorthands for the other required values.

[kizu]

Ok, but what if the zoom property would enable the containment, this way we could use zoom: 1; to do this…

Being more serious — yep, maybe having this as a sub-property of a contain (that would be available in a shorthand after a slash probably?) is a better idea than a separate property.

[mirisuzanne]

So it turns out content-visibility already has the behavior of "turning on" various types of containment behavior from outside the contain property.

It doesn't change the computed value of contain, only the used/applied value – so it's not really one property setting the other, but two properties that can trigger similar behavior. We also do this with things like block formatting context - which can now be set explicitly with contain, but is also required & applied by other properties.

[mirisuzanne]

I'm sure we'll bikeshed the details, but here's my initial attempt at a new container property:

main {
  container: inline-size;
}

This property would:

• Explicitly establish the element as a container
• Establish the types of queries allowed on the container (e.g. inline-size)
• Apply the minimum required containment to make those queries possible (e.g. layout, inline-size, and style) without changing the computed value of contain

There are several query/container "types" that we could consider values for:

• dimensional: size, inline-size (or just inline?), block-size (or just block?)
• computed values on normal/custom properties: style
• interaction states: stuck, in-view, etc…

At this point we've mostly focused on dimensional queries, but the others are discussed in #5989. What's most essential here is that the property could be extended as we add new query features. Multiple values could be supplied, and browsers would be expected to determine what containment is required for the given values:

main {
  container: size style state;
}

Bring back named containers?

I think this syntax would also open up a path to bring back named-containers -- similar to the selector argument in David Baron's initial proposal, but more flexible & customizable in the CSS. While I don't think this is needed for most dimensional queries (we almost always want the most immediate dimensions), it becomes more essential when you consider mixing different query types.

In that case, container could become a shorthand property (specific syntax TBD):

main {
  /* container: [ [<custom-ident> /]? <types>+ ] | none; */
  container: layout-area / inline-size style;
}

With two longhand variants:

main {
  /* container-type: <types>+ | none; */
  container-type: inline-size style;

  /* container-name: <custom-ident> | none; */
  container-name:  layout-area;
}

And then queries could include an optional name, before establishing conditions:

/* @container <custom-ident>? <container-query-list> { <stylesheet> } */
@container layout-area (inline-size >= 30em) { /* … */ }

This would resolve in two steps:

• Find the appropriate container...
  • if no name is specified, use the nearest ancestor container
  • otherwise, filter to the list of ancestor containers with a matching name before selecting the nearest ancestor
• Resolve the query conditions against the selected container

Considerations

While there might be some downside to triggering contain behavior from outside the contain property, I believe there is already significant precedent for that. On the other hand, attempting to shoe-horn the entire future of Container Queries into the existing contain property would be limiting, and potentially confusing:

• We might want container values that do not generate any containment behavior
• There has been significant concern about accidentally creating containers, when you only want to set containment
• The syntax would get quite cluttered to support both

Next steps

I think there are several questions to answer here:

• Do we want to add a new property for this purpose?
• Are we happy with container as a working name for the new property?
• Are we interested in pursuing named containers?
• meta: does this all belong in the css-contain spec? Or does some of it belong with css-conditional? Or somewhere else?

(I would save the specific values and other syntax details for separate issues, if we decide to go down this general path)