Re: [csswg-drafts] [css-conditional-5] Clarify behavior of named container queries in shadow trees (#12090)

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`

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


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12090#issuecomment-3204775586 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 20 August 2025 08:15:10 UTC