The draft Container Query spec describes the container query syntax in two parts:

@container <<container-name>>? <<container-query-list>> {
  <<stylesheet>>
}

Which resolve in two distinct steps:

1. container selection: Find the right container to query (nearest ancestor container, after optionally filtering by <<container-name>>)
2. query evaluation: Evaluate each feature in the <<container-query-list>>

If no eligible container is selected, the query evaluates to false.

If the selected container in step 1 is not a valid container type for the query features used in step 2, then the query evaluates to unknown. For example, if we try to query a block-size container-type about its inline dimensions, that measurement is unknown.

That means authors will likely also want to filter and select containers based on container type – eg find the nearest inline-size container in step 1, in order to query its width in step 2. And, since a <<container-query-list>> could combine multiple different features, we might need to select for more than one container type.

Since container-names are custom identifiers, and container types are built-in keywords (with potential for new additions later on) we'll need some way to distinguish them — either by requiring dashed-idents for names (not a great option), or by adding distinct syntax for selecting each one in the @container rule. Something like:

@container <<container-name>>? type(<<container-type>>+)? <<container-query-list>> {
  <<stylesheet>>
}

@container sidebar type(inline-size style) (width > 30em) and (--card: small) {
  <<stylesheet>>
}

• Is there a better approach than adding a type() function, or a better name for that function?
• Do we need clearer delineation between the selection & query aspects of the @container rule?