[css-contain] How does @container resolve when no ancestor containers have been defined?

[mirisuzanne]

Conditions in the @container rule currently query the nearest ancestor with appropriate containment for each element selected inside the conditional block. If there are no ancestors with appropriate containment, we could simply consider it a false condition.

On the other hand, we might be able to fallback to a query of the viewport or :root element. That fallback would behave similar to a media-query, though possibly with advantages (like access to the actual root font-size, rather than the browser default). On first glance, that seems like the best option. It means that container queries always have an implicit container, and always respond to the best of their ability. But in some cases it sets up a false assumption that the viewport size has anything at all useful to provide, or can be substituted directly in a useful way.

I expect authors to run into issues either way, but:

• If we do not provide an implicit fallback, authors can always add root containment to create their own
• If we do provide an implicit fallback, authors don't have any way to avoid it without creating more nested containers

Based on that, I might be leaning towards no implicit fallback root.

[kizu]

I vote for an implicit fallback root option.

My reasoning: with MQ it is a common practice (questionable, but exists) to define all the styles only for the appropriate scopes. If someone would apply this for the CQ, then if they would have an explicitly defined container, the styles would work perfectly. However, in case the container would lose its containing property or the component would be inserted somewhere without it, the styles would stop from working completely (or would lose some important parts if some of the common styles were moved outside of the CQ, but the important parts were divided by width scopes only).

On the other hand, I can't think of a use case where authors would want to avoid the implicit fallback.

If we do not provide an implicit fallback, authors can always add root containment to create their own

I find this a false assumption, if we're looking at a single component separated from any context, it can't set the containment around itself on its own. Making it so the authors are required to set the containment in every case makes the components much less reusable.

[mirisuzanne]

I took this question to Twitter yesterday, and the conversations have been interesting. A few things to note:

• There is a common first-instinct to expect a root/viewport as a fallback. It is, in many ways, the outermost container on a page, and reasonable to think about it that way.
• As people dig in, there are some clear problems with responding to the root/viewport, which will likely return much larger dimensions than are actually available to a given component. If authors take a mobile-first, progressive-enhancement approach to their queries, the "small-screen" default (without queries) will be a "safer" fallback in many cases. We can see this in the codepen demo by @dvdherron, by changing the selector on the first block of CSS to html, or removing it entirely. In this case the default without queries behaves better than a root fallback. It seems like there are many cases where a root fallback could make things worse. The intended layout:
  
  If root acts as the container, all three blockquotes get their largest-container layout:
  
  If no container queries are applied, all three quotes get the smallest ("safest"?) layout:
  
• Still, many people have other reasons that they want to set containment on the root. While media-queries rely on "viewport" values (default browser em size, etc), a root container query may be responsive to actual font size (using ems in the query), or other properties and states of the root element.

I don't think either approach will "just work" as a fallback in all situations, but my conclusion here is:

• We should allow root containment, but
• We should leave it up to authors to apply as they see fit

[css-meeting-bot]

The CSS Working Group just discussed [css-contain] How does @container resolve when no ancestor containers have been defined?, and agreed to the following:

• RESOLVED: have container MQ not resolve when there is no ancestor container

The full IRC log of that discussion

<dael> Topic: [css-contain] How does @container resolve when no ancestor containers have been defined?
<dael> github: https://github.com//issues/6178
<dael> miriam: Initial proposal was if not container as explictly defined we'd fall back. Root element or viewport. Some sort of fallback for container queries so they always resolve against something
<iank_> a fallback to something random seems pretty bad to me.(?)
<dael> miriam: Not convinced. When writing a container query assuming it's close to actual size. Fallback to full viewport will be dramatically wrong in a lot of cases. IF authors are using current best MQ best practice for smaller layouts inside they get smaller fallback
<dael> miriam: If can have containment on root you can make the choice yourself. Popular to do, but risky fallback
<dael> miriam: We should not try and salvage container queries when there is no container
<dael> iank_: Agree. Sounds pretty hostile to fallback to something unexpected
<dael> astearns: I voted for root in twitter but you have convinced me I was wrong
<dael> astearns: Prop is have MQ not do anything if no container to measure against
<dael> miriam: Correct
<dael> florian: Reasonable
<dael> astearns: Obj to have conainer MQ not resolve when there is no ancestor container
<dael> RESOLVED: have container MQ not resolve when there is no ancestor container