[css-contain-3] Determine container type automatically from the query

[fantasai]

With the ability to query computed style, that could theoretically be done on any element, having container queries look up to the nearest container of any type and then resolve any inapplicable queries as unknown is... maybe not the most convenient behavior for authors, as defining an intervening style query container between an element and its previously-eligible size query container would break those queries. Could we let the UA automatically filter the query containers based on the queries used to include only containers of compatible queryability?

[andruud]

Perhaps it makes sense to go "name ONLY" for the explicit container selection, and use "nearest 'compatible' container" by default. Do we really need explicit container selection based on type if it can be deduced from the main query?

I.e. @container <name>? <query> (no slash).

Assuming we're actually OK with a weird "secondary" interpretation of the query. (The same query would be responsible for both selecting a container to evaluate against, and also producing the main query result, might be confusing).

[una]

I agree with @andruud about nearest container type. I think being more explicit about requiring container typing will be a better developer experience than everything-is-a-container (which can create unintended confusion, see my comment here. (This perspective goes against the decision made this week to have everything as a style container by default)

[mirisuzanne]

I think there are some interesting issues to balance here, and they relate back to the resolution we took this week on #6393 (including weather we need to revisit that resolution).

Assuming we move forward with that resolution in place, I think there are several questions about how we would implement this. Primarily: how does the implicit container-selection process relate to the explicit container-selection?

• If you provide a container name, does that add to or override the implicit type-based selection?
• If you provide a container type, does that add to or override the implicit type-based selection?

Another question is how granular is the implicit selection? Does it simply see size vs style queries, and filter to all size/style containers? Or does it parse size queries in order to filter containers on the proper axis?

[mirisuzanne]

Sorry this is a long one. There are three big syntax issues currently under discussion, all related to how containers are selected for a given query. I want to summarize them all in one place, to show how they interact, and propose a path forward for all three.

Intro to container selection

@container (inline-size > 40em) {
  .card {
    padding: 1em;
  }
}

In order to resolve a container query like the one above, we have to do three things:

1. Selector Matching: Once we match each .card element in the DOM, we have to do the next steps individually for each one. Different .card elements may have different containers, making the query true or false depending which container is queried.
2. Container Selection: The current WD spec looks for the nearest ancestor container of each card element, where a container is defined by having a set container-type. However we resolved recently to give every element a default container-type: style, which breaks that logic. These issues include revisiting that resolution, but also push forward on the implications of it.
3. Resolving Queries: Once we know what container to query for a given .card element, we can resolve the queries against the container, and conditionally apply our styles.

Currently the @container syntax is broken into two parts:

1. a preamble that handles any explicit container selection
2. followed by a list of queries

@container <preamble> <query-list># {
  /* styles */
}

The three issues being discussed

There are three issue threads involved in this conversation:

1. #6644 [css-contain-3] Determine container type automatically from the query
2. #6393 [css-contain-3] Provide a syntax to query a specific container-type
3. #6876 [css-contain-3] Multiple container-queries with multiple containers

These issues all focus around the logic & syntax for container selection -- and how that impacts the preamble syntax. However, the implications of each issue are highly intertwined, so I'd like to discuss them all as a group. From there we can break out individual resolutions.

(Some of these issues are framed around the idea of style queries. There's been a suggestion that we should defer style queries to level 4, and I'm in favor of that move if it helps clarify implementation priorities. But that won't allow us to defer these questions, which impact the overall syntax of container queries.)

Current behavior is problematic

The current situation isn't ideal. Let's start with the following html. To avoid the question (for now) about style containers being automatic, I've listed the style type explicitly on every element.

<html style='container-type: size style;'>
  <main style='container-type: inline-size style;'>
    <section style='container-type: style;'>
      <div class='card'>...</div>
    </section>
  </main>
</html>

Given that markup, we can consider various container queries that apply to the card element:

/* requires either a `size` or `inline-size` container-type */
@container (inline-size > 40em) {
  .card { margin: 2em; }
}

/* requires a `size` container-type,for both inline and block size */
@container (orientation: portrait) {
  .card { margin: 2em; }
}

/* requires a style container-type */
@container style(font-style: normal) {
  .card { font-style: italic; }
}

/* requires a style container and an inline-size container */
/* TBD: do they have to be the same container? */
@container style(font-style: normal) and (inline-size > 40em) {
  .card { padding-inline: 2em; }
}

In the current spec, containers are selected by:

• Any element with a container-type is considered a container
• All query conditions are resolved against the nearest ancestor container of any type, unless otherwise specified by an explicit name/type in the preamble.
• If the queried container is the wrong type for a given condition (e.g. a size condition and style container) then the query fails. We can think of this as a potential false negative -- the answer is simply not available.

That means all of the size conditions above would return false no matter the actual size available, since the default container for our .card (it's direct parent) is only able to resolve style queries. That brings us to the first issue…

#6644 Determine container type automatically from the query?

The proposal here is to allow the conditions themselves to impact the container selection process, so that we use the nearest appropriate ancestor container based on what type of container is needed to answer the conditions raised:

• If a condition requires inline-size knowledge, select from ancestor containers with size or inline-size container-type
• If a condition requires block-size knowledge, select from ancestor containers with size container-type
• If a condition requires style knowledge, select from ancestor containers with style container-type (currently all of them, but we'll come back to that).
• Etc, as new container/query types are added, the selection mechanism can expand to handle their needs.

This is the behavior @fantasai are proposing. We think this approach will:

• help authors avoid false-negatives when an improper container-type gets added between the element and its intended container.
• encourage a best-practice of using named containers when it's important to query against a specific container.
• allow us to remove the preamble syntax for explicitly querying a given container-type, since that's now handled for us. I don't see any use-case for altering that implicit selection.

This is even more urgent, since we resolved previously (in #6393) to make container-type: style the default value on all elements -- which would mean that the nearest ancestor container of an element is always the direct parent. This proposal resolves that potential issue, while also making it impossible for the author to accidentally get themselves in the same situation.

But this decision has implications for the other two issues…

#6393 Provide a syntax to query a specific container-type

@una has pointed out that making every element a style container is only useful when querying inherited styles. For example, if you query the background-color of a container, it may not be set on the parent, but on an arbitrary ancestor.

If I understand right, she's proposed that we reverse our decision on #6393 (making every element a style container), and also reject the automatic selection above. In fact, if we reject automatic container selection,
I think we have to reverse the style container choice.

That would take us back to:

• All containers are explicitly generated by the author
• All container queries use the nearest container, even if the type will cause an instant false negative.
• To avoid that risk, authors will need to always specify the name or type (or both) explicitly in the container preamble.

While I agree that the parent element will be the wrong choice for some non-inherited styles, I expect inherited styles to be a very common use-case:

em { font-style: italic; }
@container style(font-style: italic) {
  em { font-style: normal; }
}

(This is the same functionality proposed elsewhere as a toggle() function -- which was recently deferred to css-values-5.)

Additionally, the argument seems circular to me. If selecting the appropriate type is only useful for avoiding false negatives -- but not specific enough to ensure we're always getting the most useful container -- then container-type isn't what authors should use for explicit container selection. With or without the default container-type, it would be fragile to assume that the nearest style container will always have a background. Authors should be encouraged to use a container-name whenever that level of specificity is needed, (e.g. setting container-name: has-bg).

#6876 Multiple container-queries with multiple containers

The last issue is still an open question no matter how we resolve the other two issues -- but it becomes especially relevant to clarify if we follow the path @fantasai and I are proposing.

If we look at two of the single-condition queries above, each one will now seek out the appropriate container to resolve the condition:

/* use the  `main` container: nearest inline-size type */
@container (inline-size > 40em) {
  .card { margin: 2em; }
}

/* use the `section` container: nearest style type */
@container style(font-style: normal) {
  .card { font-style: italic; }
}

But what happens if we combine the two conditions in a single query? What container/s are selected?

@container style(font-style: normal) and (inline-size > 40em) {
  .card { padding-inline: 2em; }
}

We have a choice:

1. Use the nearest single container that is able to resolve all conditions
2. Allow each condition to select a different container.

The first option (which we prefer) means the way you ask the question might change the answer you get. But it helps keep things simple: a single container query rule only needs a single container-selection preamble, and can always be resolved against a single container.

It's still possible to query multiple containers by nesting the queries:

@container style(font-style: normal) {
  @container (inline-size > 40em) {
    .card { padding-inline: 2em; }
  }
}

Nesting gives us the AND of two queries referencing two containers. The OR version requires duplicated styles, which is less ideal, but still possible. Down the road, we could still consider adding syntax sugar for this -- using the @when rule, or something similar that can wrap our existing single-container syntax in distinct functions. That can be deferred for now without holding up progress on the core functionality.

The second option means a single query can (and will often) be resolved against multiple containers. That also means we would want a unique preamble for each condition. There have been a few syntax proposals thrown around, but so far nothing that strikes me as clear and legible. I'm not convinced it's a appropriate syntax sugar, if it makes the simple use-case more complicated.

Proposed resolutions for each issue

1. #6644 When selecting a container, determine a container-type automatically based on the combined condition-types required in the query.
2. #6393 Remove the container-type syntax from the preamble of the @container rule.
3. #6876 A single @container rule resolves all conditions against the same container by default. Defer the question of additional syntax sugar to level 4.

And a possible follow-up:

4. #7020 Defer style containers and conditions to level 4

[css-meeting-bot]

The CSS Working Group just discussed CSS Container Queries Level 3, and agreed to the following:

• RESOLVED: when we select a container, we determine which container by looking at the actual queries and finding an appropriate container for the questions being asked
• RESOLVED: remove the container-type syntax from the preamble of the @container rule
• RESOLVED: All queries in an @container rule are against the same container, which can answer them all
  XXX* RESOLVED: defer style containers to L4XXX

The full IRC log of that discussion

<fantasai> Topic: CSS Container Queries Level 3
<fantasai> miriam: All three of these issues are around how we handle container selection
<fantasai> miriam: which is, in a container query, we have to find a container to ask the questions
<astearns> github: https://github.com//issues/6644#issuecomment-1033245188
<fantasai> miriam: and once we've selected a container can query against it
<fantasai> miriam: these are all issues around how we find that container
<fantasai> miriam: 3 issues being discussed, I think it all ties together in the first one, so will start there
<fantasai> miriam: Current logic is any element with container-type is a container
<fantasai> miriam: and always look to nearest container for querying
<fantasai> miriam: so quite easily to get false negatives if you ask a query that that container type doesn't support
<fantasai> miriam: so looking at how to avoid that
<fantasai> github: https://github.com//issues/6644
<fantasai> miriam: Proposal here is to look at the different conditions being asked
<fantasai> miriam: is it asking for inline-size, block-size, style
<fantasai> miriam: instead of looking for nearest container, can look for nearest container of a type that can answer all the queries
<fantasai> miriam: This ties into earlier decision that all elements are style containers
<fantasai> miriam: if all are style containers, then nearest container is always the parent, so this exacerbates the problem
<fantasai> miriam: most queries will want to look higher in the chain than the parent
<fantasai> miriam: even if we reverted that, though, we still have this issue
<fantasai> miriam: fragile to assume that no container will be inserted between you and what you're trying to query
<fantasai> miriam: so I think we want to solve this issue regardless
<fantasai> miriam: Una wanted to return to that decision
<fantasai> miriam: could potentially punt on having style issues
<fantasai> miriam: third issue is, if looking for inline-size container and style query looking for style container
<fantasai> miriam: can nest those
<fantasai> miriam: and then each query looks for its own container
<fantasai> miriam: could also combine multiple queries in a single @container rule
<fantasai> miriam: in this case, are we querying a single container or multiple containers (per query)?
<fantasai> miriam: proposal is in the issue [LINK PLEASE!!!]
<fantasai> miriam: and then Jen Simmons was asking about deferring style queries entirely
<fantasai> miriam: so that's the overall summary
<astearns> the links are all in the comment at the top of this minuting section, and the topic in the channel
<chrishtr> q+
<fantasai> chrishtr: What is the implementation complexity and runtime implication of these changes?
<miriam> Issues are 6644, 6393, 6876, and 7020 to defer
<fantasai> miriam: I haven't gotten any pushback form engineers I've talked to
<fantasai> chrishtr: Anders and Rune think it's doable?
<una> q+
<astearns> ack una
<astearns> q+ una
<astearns> ack chrishtr
<fantasai> fantasai: Can't imagine there's any runtime complexity, just deriving type from query, not looking at the document tree at all, and then back to where you were when we had to have an explicit type
<fantasai> astearns: I assume spec would need to be clear how the queries select for container types?
<fantasai> astearns: but that seems simple enough to me
<astearns> ack una
<fantasai> una: I want to add that it seems doable, you'd still have to specify a container type whether explicitly or whether stating in container query
<fantasai> una: I like the idea of determining type based on the query, only writing in one place
<fantasai> una: I still dislike everything being a style query by default
<fantasai> una: In order to have 6644, we'd have to revert 6393
<fantasai> miriam: I don't understand why we would have to revert
<fantasai> una: wouldn't having everything be a style container interfere?
<fantasai> miriam, fantasai: no
<fantasai> fantasai: Not making every query a style query, making every container a style query container
<fantasai> astearns: still means your style query looks up to a parent every time
<fantasai> miriam: yes, but I don't think that's a problem
<astearns> s/a parent/the immediate parent/
<fantasai> miriam: In my mind, we should be encouraging authors that if they are relying on something that might move, might have a new container in between, need to use a name
<jensimmons> q?
<fantasai> miriam: If you're looking for background-color ancestor, need to use name to filter the ancestors, shouldn't rely on being nearest style query container because might insert another style query container in between for other purposes
<fantasai> astearns: any other questions or comments about selecting the container based on query characteristics?
<fantasai> jensimmons: I think it's a good idea to have sensible defaults so that the browser chooses containers instead of defaulting to something that doesn't work
<fantasai> jensimmons: In chatting with our engineers, sounds like we don't have implementation concerns
<fantasai> astearns: Shall we make this resolution and move on?
<fantasai> +1
<fantasai> astearns: Proposed that when we select a container, we determine which container by looking at the actual queries and finding an appropriate container for the questions being asked
<fantasai> RESOLVED: when we select a container, we determine which container by looking at the actual queries and finding an appropriate container for the questions being asked
<fantasai> miriam: Next, is there any reason to keep an explicit container type argument in the preamble?
<fantasai> miriam: since we're already automatically determining it
<fantasai> astearns: what else goes in preamble?
<fantasai> miriam: name and type, would drop type but keep name and that simplifies the syntax
<fantasai> +1
<fantasai> una: I'd prefer to write explicitly, but if not majority opinion ...
<fantasai> una: interested in hearing others
<fantasai> una: I think default of style queries is unclear
<emilio> +1
<fantasai> una: would prefer each time you specify the query type
<fantasai> una: I don't think this works in default case because of everything being a style query
<fantasai> miriam: We're already looking for the right type of container
<fantasai> miriam: so I'm saying we can remove that type from the preamble from the container rule, now that it's automated
<fantasai> una: sounds good to me
<fantasai> jensimmons: What's the preamble?
<fantasai> miriam: @container starts with a preamble for selecting the right contianer
<fantasai> miriam: right now allows choosing type of contianer and name of container, before the query
<TabAtkins> The part between the at-keyword and the {} block.
<TabAtkins> (I call this "prelude" in Syntax.)
<fantasai> miriam: suggesting we drop the type keyword, since we can automatically determine that
<TabAtkins> Ah no preamble is a subset if the prelude, I see
<fantasai> astearns: No use case for wanting to query a more limited set of containers than the query needs?
<fantasai> fantasai: Better in that case to use a named container
<fantasai> astearns: Seems we could add it later if needed
<fantasai> astearns: Anyone else with concerns about removing container type form the preamble?
<fantasai> RESOLVED: remove the container-type syntax from the preamble of the @container rule
<fantasai> miriam: This is where we could reconsider the style default, or delay implementation of style queries to L4 and bring it back later
<fantasai> miriam: or we can discuss it now
<fantasai> miriam: whether a default of style container is good to have on every element
<TabAtkins> Yeah I'm quite happy with this latest resolution
<fantasai> astearns: I'm concerned that we will constrain ourselves if we push this off
<fantasai> fantasai: I think we should take it up, style queries are not that complicated
<fantasai> fantasai: and I support Miriam's take on this issue
<fantasai> astearns: That is?
<fantasai> miriam: The default style query type is very useful for a lot of cases, particularly for inherited properties
<fantasai> miriam: e.g. query the font-style style of the parent and flip it from italic to normal or vice versa
<fantasai> miriam: would replace the toggle() feature that had been proposed
<fantasai> miriam: It's helpful in many situations
<fantasai> miriam: and for cases where you're looking at a non-inherited property, want to look for a specific container
<fantasai> miriam: and in that case should be looking for a named query, not relying on the container type
<fantasai> miriam: So my argument is it's a good default, it helps some cases though not all of them, and for cases where it doesn't should be using a name anyway and we should encourage that
<fantasai> una: My thought on this is, it feels a bit brittle to me
<fantasai> una: If you add an additional element between the container you're querying and the query, breaks your query
<fantasai> una: You have to go up the tree for many things, so looking at the parent feels brittle to me
<fantasai> astearns: I'm also leaning Una's way, since we made this other change to avoid the mistake of selecting the direct parent; odd to leave that in place
<emeyer> scribenick: emeyer
<miriam> q+
<emeyer> fantasai: Two arguments. One, on the issue of being brittle and easy to break, yeah. If you were relying on a container type lookup, and some other type of query container gets in between, that will break. If we’re consistently looking at the parent, things become very predictable for authors. It becomes clear that naming is needed to break that nearest-container behavior.
<emeyer> …The second thing is that there are a lot of cases where the ability to just look at your parent is useful. I suspect there will be a number of pages that want to set this on every element on the page just to get that ability. If they do that, then the entire tree has a non-default value and that’s not performant.
<astearns> ack fantasai
<jensimmons> q+
<emeyer> …I think it’s going to be easier for authors to understand what they’re doing if we have the default be that every element is a style query container. That gets us default behavior of the parent being the initial thing to look at. We’ve had multiple request for features to look at the parent for something. This would deliver that very easily.
<emeyer> …So I think we should do this. It will be a useful feature and cause less breakage rather than more.
<fantasai> astearns: Yes, we have a lot of requests for a parent selector thing, but this is a container feature
<fantasai> astearns: might be a source of confusion
<astearns> ack miriam
<fantasai> astearns: You mentioned can get into bad state by adding another explicit container to the hierarchy. If you add a container, queries will respond, different than just adding an element
<fantasai> miriam: That gets into what I was going to add to what fantasai was saying
<una> q+
<fantasai> miriam: When you're dealing with inherited properties, and just want to check the parent, adding any element will break it.
<fantasai> miriam: let's use <strong>, I want it to respond to whether parent is bold or not bold and do something based on that
<fantasai> miriam: if parent changes to something no longer container, and changes whether we're in bold or not bold, then any element breaks that use case
<fantasai> miriam: the inherited property use case is only useful if we assume we can get the right answer from the parent
<fantasai> miriam: and I'm guessing we'll get a "best practice" where people set style containment on every element
<astearns> ack jensimmons
<fantasai> miriam: and as fantasai said, that will create a performance hit
<fantasai> jensimmons: I feel from an author's perspective, the proposal that Miriam has put together is the best way to go
<fantasai> jensimmons: I understand what Una is saying that in big projects, it doesn't give a lot of functionality. THey want to create components and style systems and have no idea what the DOM is going to be
<fantasai> jensimmons: but I think that's true for a lot of CSS, where the simple way, the default of CSS doesn't hold up in big projects, and more powerful tools are needed
<fantasai> jensimmons: and that's what container names are for
<fantasai> jensimmons: But there really are many many projects that are not multimillion dollar projects
<fantasai> jensimmons: and this simple querying that we're discussing, with the font-style: italic query example, it's so nice and expands what's possible
<fantasai> jensimmons: I don't think we should break that because the big projects need something else
<astearns> ack una
<fantasai> jensimmons: Philosophy in CSS should be to give simple defaults that work for the small projects, and give more powerful tools for the big projects
<fantasai> una: I don't see this a large or small project thing
<fantasai> una: My concern is that the DOM change so quickly, you have a paragraph inside a list and link inside, so lots of layers already
<fantasai> una: and not realize that you're not directly within a parent
<fantasai> una: 2nd question, example of font-style italic
<fantasai> una: what happens when you have an em that also has a span and then a link inside of that?
<TabAtkins> Miriam's point is that in that nested case you *can* generally depend on the parent for style, because you very likely want the inherited value. If you don't, then you should be explicitly naming on both sides.
<fantasai> una: This is where the uncertainty of the output comes to me
<fantasai> una: I don't see the direct parent, you don't know as a publisher what the output DOM would be
<fantasai> una: So I see this getting murky
<fantasai> una: But there is room from dev perspective to get really clunky, and generally expanding more into component queries it get less useful
<fantasai> una: Is this going to introduce confusion if not fully aware of what DOM looks like?
<fantasai> una: Is this going to be majority use case, worth a default?
<fantasai> astearns: One thing that made me possibly reconsider, you're talking about clunkiness, for the cases that you're concerned with, authors can use container names
<fantasai> astearns: but if we do not have the style container be the default for all elemets, then in order to serve that use case, then there needs to be a reset with * { container-type: style }
<fantasai> astearns: which seems even more clunky than using container names
<fantasai> una: So you'd need a container name?
<fantasai> miriam: Right. You'd need it to be always the parent for it to work.
<fantasai> una: Yeah, that's the strongest argument I've heard
<fantasai> miriam: And to me, brittle DOM is an argument for this. Or rather, it's an argument for always using a container name when you need the DOM not to be brittle.
<fantasai> una: Sounds like it would be a best practices / education point then
<fantasai> una: That last point really drove this home
<fantasai> astearns: I'm really concerned about the teachability of this
<fantasai> astearns: We've got explicit containers, and also implicity style queries.
<fantasai> astearns: But it does seem to be the best default to start with
<fantasai> astearns: So spec currently says that style containers are the default?
<fantasai> miriam: I'm not sure that's in the spec yet, but it was resolved
<fantasai> astearns: What if we don't re-resolve, just leave things as they are and give Una and whoever else some time to come up with arguments for changing back?
<fantasai> una: works for me
<fantasai> una: I definitely see both sides of this
<fantasai> una: want consistency for the spec
<fantasai> astearns: Anything more on this issue?
<TabAtkins> ack
<TabAtkins> ack TabAtkins
<fantasai> miriam: Need to clarify when multiple queries in a contianer rule, would they individually select different containers
<fantasai> miriam: I think we should resolve that for a given @container rule, select a single container for all queries in it
<TabAtkins> Strong+ on this new resolution
<fantasai> miriam: not different containers for each query within the @container
<fantasai> astearns: We would have that with nested @container queries, right? SO this would just be about adding easier syntax
<emeyer> fantasai: I’m a strong +1 on this resolution
<emeyer> …If we want to do mixed in a single statement, that’s an argument for syntax that allows you to flatten nesting.
<una> LGTM
<fantasai> s/for syntax/for using @if/@when syntax/
<fantasai> astearns: Proposed that we check all queries against a single container that can answer them all
<fantasai> RESOLVED: All queries in an @container rule are against the same container, which can answer them all
<fantasai> astearns: Next question is whether to punt on style queries
<fantasai> astearns: Since we still have this open question of whether to make all elements style containers, we should punt?
<fantasai> jensimmons: yes please
<fantasai> RESOLVED: defer style containers to L4

[astearns]

We did not resolve to defer style containers to L4 (the official minutes will correct this). We still could defer, but it will be better to continue considering how they will interact with the rest of the feature for now.