[css-conditional-5] Clarify behavior of named container queries in shadow trees

[frehner]

The spec currently says

Style rules applying to a query container’s flat tree descendants can be conditioned by querying against it, using the @container conditional group rule.

Which was aligned here #5984 (comment)

The spec also does not carve out an exception for named container queries, so my assumption would be that they should also follow the same rule.

However, WPT has tests specifying that named container queries set inside of a shadow tree do not behave this same way, and currently all browsers are (mostly) compliant with those tests.

If this carve-out was intentional for named container queries, I think it would be nice for the spec to be updated to reflect that. If it's not intentional, then perhaps the WPTs should be reversed.

[mirisuzanne]

For context: The initial spec made containers inside shadow DOM entirely hidden from light-style queries. The theory was that internal containers are an implementation detail, and shouldn't be exposed. That makes some sense, except that there's no way to select the slot of an element, and query that as a container. So this often required extra elements (similar to grid cells, I suppose).

We reverted that because it seemed like container units should resolve on the flat tree, and that container units should resolve the same as queries. I also argued that containers are about getting information from context – much like inheritance, which works on the flat tree. Style queries make that association even more explicit, since the goal is often to query the value that will be inherited on a property.

In making that change, we didn't specify the question of container names. It does seem to me though that "Container queries and units use the flat tree" would include container names. That seems to me like the WPT is out of date.

[frehner]

I believe @lilles added the container name WPT tests here web-platform-tests/wpt#46687 which looks like it originated in Chromium.

Maybe there's some context we can gain there?

[frehner]

I realized I never left an opinion here, so if you don't mind...

I'm in the situation of created a web-component-based library. Things such as <my-button>, <my-stack> etc.

One of the components I'm also creating is a Container Query component: <my-container>. It default to container-type="inline-size". It also allows you to add a container-name through an attribute containername="custom-container-name". Ideally these styles would be placed on an element in shadow-dom that wraps the slot, e.g.

<my-container>
  <template shadowrootmode="open">
    <div style="container: {name} / inline-size;">
      <slot></slot>
    </div>
  </template>
</my-container>

Imagine now that a dev using my library wants to use the components in the following way:

<my-container name="outer">
  <my-stack>
    <my-container name="inner">
      <my-button>hi</my-button>
    </my-container>
  </my-stack>
</my-container>

Given that named containers currently do not escape the flat tree, this is nearly impossible to provide to consumers of my library without some crazy hacks.

If you take the names away, you cannot target the previously-named "outer" container from <my-button>.

---

Another, maybe simpler, situation is where you have a <my-page> element, and you want to allow consumers of your library to query how wide the "page" is.

However, what if another <my-container> sits between <my-page> and <my-button>? Now the button doesn't have access to <my-page>'s unnamed query, and it also cannot access it if we try to name it. :(

<my-page>
  <template shadowrootmode="open">
    <div style="container: page / inline-size">
      <slot></slot>
    </div>
  </template>
  <my-container>
    <my-button>hi</my-button>
  </my-container>
</my-page>

So this feels pretty limiting to not have named container queries use the flat tree. :)

[mirisuzanne]

Agenda+ to clarify the intention of our previous resolution

[lilles]

In making that change, we didn't specify the question of container names. It does seem to me though that "Container queries and units use the flat tree" would include container names. That seems to me like the WPT is out of date.

Keeping container-name as a tree-scoped name/reference was intentional from my side.

The spec currently does not say that container-name is not tree-scoped, which I think makes it one per https://drafts.csswg.org/css-scoping/#shadow-names

When it comes to implementations, it looks like Chrome and Safari treats it as a tree-scoped reference, while Firefox doesn't.

If it should not be tree-scoped, we need to resolve on that at make it explicit in the spec.

[css-meeting-bot]

The CSS Working Group just discussed [css-conditional-5] Clarify behavior of named container queries in shadow trees, and agreed to the following:

• RESOLVED: Container names are not tree-scoped

The full IRC log of that discussion

<fantasai> astearns: Miriam, you had a question about the resolution here?
<fantasai> miriam: Rune clarified his intent, but we didn't clarify intent as a group
<fantasai> miriam: This keeps coming up where authors want a way for container queries to be usable across shadow roots, that includes names
<fantasai> miriam: we've gone back and forth on what containers rae visible
<fantasai> miriam: but in some implementations names are not available
<fantasai> miriam: can you reference a container name across the shadow boundary?
<emilio> q+
<futhark> q+
<astearns> ack emilio
<fantasai> emilio: On one hand, we resolved that CQ work on flat tree rather than shadow tree
<fantasai> emilio: so seems potentially consistent to expose the name
<fantasai> emilio: I don't mind either way
<astearns> ack futhark
<fantasai> futhark: Wrt whether container-name is global or tree-scoped
<fantasai> futhark: working with slotted
<fantasai> futhark: would have to make it global
<fantasai> futhark: but we need to make it explicit in the spec if we want to make it global
<fantasai> futhark: because scoping spec defaults to making names tree-scoped
<TabAtkins> I don't think I have a strong opinion here, but the arguments given by the author in the thread sound reasonable. I'm okay with making them global.
<fantasai> miriam: My proposal is to make ti global
<fantasai> astearns: any concerns with making this change?
<fantasai> lea: Is this that named container queries inside shadow would be global, or light dom would be global?
<fantasai> TabAtkins: both
<fantasai> emilio: global is global
<fantasai> emilio: sketchy case is whether a slotted element can observe a name inside the shadow tree
<lea> q?
<fantasai> emilio: I don't feel strongly either way
<fantasai> emilio: but size containment follows flat tree
<fantasai> futhark: we have interop on anonymous containers
<fantasai> lea: what happens if you're slotting an element inside a component with shadow dom around it, there is a named container inside the shadow DOM, and you have same name in the light DOM
<fantasai> lea: seems to me the light DOM should take precedence
<fantasai> emilio: well in this proposal it wouldn't
<fantasai> emilio: but if you are CQ against an anonymous container, you'd reference the shadow DOM container, not the light DOM ancestor container
<fantasai> lea: Seems surprising when, as an author, I use a component that idk internals
<fantasai> lea: and I'm using my own names for my stuff
<fantasai> lea: and shadow DOM happens to use the same name, stuff breaks, and Idk whay
<fantasai> emilio: Could make the same argument with CQ units
<fantasai> lea: I think anything that doesn't define a name is inherently looser
<fantasai> lea: container units can't specify a name, but we have an issue on that
<fantasai> lea: but in cases where you name things, you can be more specific
<fantasai> lea: for actual names to leak out it's a problem
<fantasai> lea: what issue is asking for is reasonable: if there are no conflicts in the light DOM
<fantasai> miriam: that also doesn't match how container names are used, can use them multiple times, and match to the closest one
<fantasai> miriam: so shadow vs light DOM seems ...
<fantasai> miriam: names aren't expected to be unique
<fantasai> lea: if light DOM names leak into shadow DOM, seems ok
<fantasai> lea: it's leaking from shadow outside that's a problem
<fantasai> lea: should be possible to define whatever names you want inside a shadow component, and not worry about leakage to outside
<fantasai> lea: could always prefix stuff, but point of shadow DOM was to avoid having to do that
<fantasai> emilio: Well, people disagree what shadow DOM is for. :)
<fantasai> lea: I usually argue in favor of less encapsulation
<fantasai> lea: but there's a difference between making light DOM visible to shadow, vs other way around
<fantasai> emilio: custom properties inherit through
<fantasai> miriam: CQ you're looking at close context, so more similar to custom property inheritance
<fantasai> lea: that's a good argument
<fantasai> astearns: My understanding is that current WPT do have this leakage
<fantasai> emilio: no?
<fantasai> emilio: Firefox behaves as we want to resolve
<fantasai> futhark: Yes, based on test results, FF makes them global while WebKit/Blink make them scoped
<fantasai> emilio: I've never found a compat issue, fwiw
<astearns> q?
<fantasai> lea: I find the inheritance argument compelling
<fantasai> astearns: so the proposed resolution is that CQ names are global, whether or not they're declared in the shadow DOM
<fantasai> emilio: They're not tree-scoped
<fantasai> RESOLVED: Container names are not tree-scoped