[css-scoping] [selectors] :scope and DocumentFragment / ShadowRoot #7261

emilio · 2022-05-08T21:17:15Z

Relevant spec sections are:

If I read the specs correctly:

Element.querySelectorAll(":scope > *") returns all the direct descendants of the given element. This is interoperable behavior and not ambiguous.
Document.querySelectorAll(":scope > *") ought to work and return only the root element (the scoping root would be the Document node, and it has only one child, which is the document element). Browsers are interoperable here but not following this reasoning. Instead, :scope is the root element (so such a query returns the <head> and <body> elements, usually).
DocumentFragment.querySelectorAll(":scope > *") ought to work and return the children of the fragment, because the scoping root is the fragment, and is a virtual scoping root. This works in Blink, but not in Gecko and WebKit (:scope is undefined, so it falls back to the root element of the document, so it never matches anything).
In style sheets, :scope is always the root element of the document, because there's no defined scoping node, and that's the fallback. That's Gecko and WebKit's behavior. Blink in shadow trees considers the shadow root a :scope (https://crbug.com/1272434), but :scope doesn't match the shadow host directly like :host does.

This is all very unfortunate and inconsistent. It's clear that the spec is wrong for the Document.querySelector case, IMO (though the spec doesn't define Document as a potential "virtual" scoping root, it follows that if such should work for DocumentFragment it ought to work for Document as well?).

We should probably agree on the non-interoperable cases. If we wanted to make :scope behave consistently for Document and DocumentFragment, we ought to probably either:

Make all direct children of the fragment match :scope (rather than what the spec currently says / what Blink does), or.
Leave the scope node undefined (which is what WebKit / Gecko does), so it always matches the root element as a fallback.

For the stylesheets case, I think WebKit and Gecko follow the spec and the spec is somewhat reasonable. We have :host for shadow trees, and even tho defining :scope is possible, it might be a bit tricky, depending on how we define the above.

Thoughts?

cc @tabatkins @lilles @anttijk

The text was updated successfully, but these errors were encountered:

lifaon74 · 2022-05-09T06:48:44Z

In my opinion, the :scope should match the node itself, even if it is virtual. So calling :scope > * on a DocumentFragment should returns its direct children, just as it would have happen on a HTMLElement. It solves the problem: I have a container, I want to select some of its direct children, how can I do it ? ex :scope > scope[name="abc"].

Usually, the :scope usage is coupled with custom elements.

emilio · 2022-05-09T07:11:42Z

In my opinion, the :scope should match the node itself, even if it is virtual. So calling :scope > * on a DocumentFragment should returns its direct children, just as it would have happen on a HTMLElement.

Then doing so in Document should select the root element for the same reasoning right? That's not how browsers behave right now.

Usually, the :scope usage is coupled with custom elements.

:host works like you want for custom elements across all browsers afaict.

lilles · 2022-05-09T16:51:00Z

Reading the Selectors4 spec, it looks to me that :scope always matches a true element, even if the scoping root can be a Document or a DocumentFragment/ShadowRoot? Am I reading it correctly?

https://drafts.csswg.org/selectors-4/#the-scope-pseudo says afaict that :scope must match an element?

If so, point 2. Document.querySelectorAll(":scope > *") should return body/head because the scoping root is not an Element, hence falling back to the document root element?

emilio · 2022-05-09T17:52:35Z

Hmm, I guess you're right. In which case Gecko and WebKit are just right?

lilles · 2022-05-09T18:01:01Z

Hmm, I guess you're right. In which case Gecko and WebKit are just right?

That's what it looks like to me.

astearns · 2022-05-09T23:16:40Z

@emilio can you give an update on what we should resolve on for this?

emilio · 2022-05-10T08:45:57Z

It seems we all agree on the spec meaning, so I guess what's left here is landing some tests.

lilles · 2022-05-10T10:18:46Z

There are tests with the wrong assumptions:

https://wpt.fyi/results/css/selectors/scope-selector.html?label=experimental&label=master&aligned

emilio · 2022-05-10T10:29:42Z

Those come from web-platform-tests/wpt#12252. @lilles I saw some movement in the Chromium bug, are you fixing these or do you want me to send a PR?

lilles · 2022-05-10T14:03:01Z

I have not changed them yet, so feel free to send a PR.

lilles · 2022-05-10T14:03:33Z

I won't have time to change them today, at least.

As per discussion in w3c/csswg-drafts#7261

emilio · 2022-05-11T16:34:15Z

@lilles web-platform-tests/wpt#34032

As per discussion in w3c/csswg-drafts#7261

Automatic update from web-platform-tests Clean-up and fix :scope test. As per discussion in w3c/csswg-drafts#7261 -- wpt-commits: 3bd0214afc4f254b13c65117074806bfeee0189f wpt-pr: 34032

andruud · 2023-02-16T13:20:03Z

@tabatkins seemingly made a ninja edit of the spec which is in conflict with the conclusion here. Reopening since, we probably need to change the spec or implementations.

tabatkins · 2023-02-16T18:49:21Z

Not a ninja edit! I was applying the resolutions from #6399, as the commit message says!

Further, I don't think my edits had any impact on this thread. Can you elaborate on what you think I changed that's relevant here?

tabatkins · 2023-02-16T19:00:08Z

Rune's reading:

Reading the Selectors4 spec, it looks to me that :scope always matches a true element, even if the scoping root can be a Document or a DocumentFragment/ShadowRoot? Am I reading it correctly?

Was just wrong. :scope can match a virtual scoping root, like a DocumentFragment; my #6399 edits reworded the relevant text but maintained this fact. A virtual scoping root can't be the subject of a selector, but that just means that docfrag.querySelector(":scope") won't return anything; it can still match the non-element DocumentFragment node so long as it then moves the subject to an actual element (or pseudo-element).

The relevant question for Document.querySelector() and DocumentFragment.querySelector() is just whether they pass a "scoping root" to the "match a selector" algorithm. Per DOM, it appears they do in both cases (since Document, DocumentFragment, and Element all share the same algorithm via the ParentNode mixin).

So following the specs as they are written today, document.querySelector(":scope > *") should return the html element, just as myshadowroot.querySelector(":scope > *") returns all the root nodes in the shadow tree.

(If we wanted document.querySelector(":scope") to return the html element instead, so it matched how the selector would work in a stylesheet, I think that would be fine, maybe even preferable. It just requires a small fix to DOM, not to Selectors, to selectively not pass a scoping root when called on a Document.)

andruud · 2023-02-16T19:30:47Z

OK, I may have been too quick to declare a ninja edit. [But hey, I got your attention :-)]. I did see the #6399 reference, but I couldn't immediately understand why some fix related to :has() would also (seemingly) change whether or not :scope in general could match non-elements (subject or not).

Rune's reading [...] was just wrong.

OK, but to be fair, Emilio and me (I remember looking at the spec at the time as well) also read the old spec as ":scope matches ELEMENTS ONLY". But whatever, let's move on:

So following the specs as they are written today, document.querySelector(":scope > *") should return the html element, just as myshadowroot.querySelector(":scope > *") returns all the root nodes in the shadow tree.

Yeah, that behavior makes sense. It's not what browsers implement though.

But this is good, it resolves another question I had about @scope {} (without a prelude) from a constructed stylesheet in a shadow tree. If :scope could only match real elements, then @scope { :scope > div {} } could never match anything, but with the "virtual scoping root" it could be allowed to match the shadow root.

Closing the issue again, hopefully we can change implementations rather than changing the spec.

tabatkins · 2023-02-16T20:51:46Z

Closing the issue again, hopefully we can change implementations rather than changing the spec.

I wrote it in an edit, but note that I think the current browser behavior (where :scope returns the html element, :scope > * returns body and head) is reasonable for document. I'd honestly prefer to fix the DOM spec there; it's a trivial edit.

But for document fragments (like shadow roots) :scope does indeed need to match the docfrag itself.

lifaon74 · 2023-02-18T18:38:17Z

In my opinion, document.querySelector(":scope > *") should return the document.html element and document.querySelector(":scope") the document itself.
And docFrag.querySelector(":scope > *") its child elements and docFrag.querySelector(":scope") the document fragment. This would allow a better consistency and natural interpretation. However, it could be a little confuse if we expect only Element or null as a return. In this case, we may consider querySelector(":scope") always returning null if the parent is not an Element.

In CalculateActivations, we'd previously just call Element.parentElement up the ancestor chain, therefore never reach the host. Additionally, we did not propagate the original SelectorCheckerContext.scope which is needed for :host to match. This CL uses ParentOrShadowHostElement, and adds the concept of "activation ceiling" to deal with the fact that we need to look at one element *above* the current activation root when that root is a ShadowRoot. Note that :scope is supposed to be able to match "virtual" roots [1] (like a ShadowRoot), but Blink does not support this in general. This CL does not address this issue. [1] w3c/csswg-drafts#7261 Bug: 1280240 Change-Id: I2d0be103f4cd02ec576711b959e075a5118e694a

In CalculateActivations, we'd previously just call Element.parentElement up the ancestor chain, therefore never reach the host. Additionally, we did not propagate the original SelectorCheckerContext.scope which is needed for :host to match. This CL uses ParentOrShadowHostElement, and adds the concept of "activation ceiling" to deal with the fact that we need to look at one element *above* the current activation root when that root is a ShadowRoot. Note that :scope is supposed to be able to match "virtual" roots [1] (like a ShadowRoot), but Blink does not support this in general. This CL does not address this issue. [1] w3c/csswg-drafts#7261 Bug: 1280240 Change-Id: I2d0be103f4cd02ec576711b959e075a5118e694a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4272396 Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1108363}

Automatic update from web-platform-tests [@scope] Support @scope (:host) In CalculateActivations, we'd previously just call Element.parentElement up the ancestor chain, therefore never reach the host. Additionally, we did not propagate the original SelectorCheckerContext.scope which is needed for :host to match. This CL uses ParentOrShadowHostElement, and adds the concept of "activation ceiling" to deal with the fact that we need to look at one element *above* the current activation root when that root is a ShadowRoot. Note that :scope is supposed to be able to match "virtual" roots [1] (like a ShadowRoot), but Blink does not support this in general. This CL does not address this issue. [1] w3c/csswg-drafts#7261 Bug: 1280240 Change-Id: I2d0be103f4cd02ec576711b959e075a5118e694a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4272396 Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1108363} -- wpt-commits: 37ffe7edc5b6400a16ba6511ba2fd392ab8be318 wpt-pr: 38610

In CalculateActivations, we'd previously just call Element.parentElement up the ancestor chain, therefore never reach the host. Additionally, we did not propagate the original SelectorCheckerContext.scope which is needed for :host to match. This CL uses ParentOrShadowHostElement, and adds the concept of "activation ceiling" to deal with the fact that we need to look at one element *above* the current activation root when that root is a ShadowRoot. Note that :scope is supposed to be able to match "virtual" roots [1] (like a ShadowRoot), but Blink does not support this in general. This CL does not address this issue. [1] w3c/csswg-drafts#7261 Bug: 1280240 Change-Id: I2d0be103f4cd02ec576711b959e075a5118e694a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4272396 Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1108363}

Automatic update from web-platform-tests [@scope] Support @scope (:host) In CalculateActivations, we'd previously just call Element.parentElement up the ancestor chain, therefore never reach the host. Additionally, we did not propagate the original SelectorCheckerContext.scope which is needed for :host to match. This CL uses ParentOrShadowHostElement, and adds the concept of "activation ceiling" to deal with the fact that we need to look at one element *above* the current activation root when that root is a ShadowRoot. Note that :scope is supposed to be able to match "virtual" roots [1] (like a ShadowRoot), but Blink does not support this in general. This CL does not address this issue. [1] w3c/csswg-drafts#7261 Bug: 1280240 Change-Id: I2d0be103f4cd02ec576711b959e075a5118e694a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4272396 Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1108363} -- wpt-commits: 37ffe7edc5b6400a16ba6511ba2fd392ab8be318 wpt-pr: 38610

andruud · 2023-08-14T08:42:52Z

So following the specs as they are written today, document.querySelector(":scope > *") should return the html element, just as myshadowroot.querySelector(":scope > *") returns all the root nodes in the shadow tree.

Yeah, that behavior makes sense. It's not what browsers implement though.

Actually, no, that does not make sense for shadow roots, because the shadow root itself does not exist for the purposes of selector matching (when matching in the context of that shadow tree):

Scoping:

When a selector is matched against a shadow tree, the selector match list is initially the shadow host, followed by all children of the shadow tree’s shadow root and their descendants, ordered by a pre-order traversal.

Also, to reinforce that:

For the purpose of Selectors, a shadow host also appears in its shadow tree, with the contents of the shadow tree treated as its children. (In other words, the shadow host is treated as replacing the shadow root node.)

This is aligned with the current behavior of all browsers as well. To visualize:

If this matches:

:host > div { ... }

then this can't also match:

:scope > div { ... }

At least not as long as :scope points to the shadow root.

`el.shadowRoot.querySelector` uses a `ShadowRoot` as the root of the query, not an `Element` so we should support that. The behavior of `:scope` seems to be a little weird, but Chrome also returns `null` when used in a shadow root. This [csswg issue](w3c/csswg-drafts#7261) has some ambiguity, but it seems that because browsers don't see shadow roots as elements, `querySelector` can't return the `ShadowRoot`. I think the best behavior we can do is just type `null`.

This special path causes :scope selectors to incorrectly match ':scope *' selectors in shadow roots, when it actually should match nothing [1]. The provided test scope-pseudo-in-shadow.html is passing in Firefox and Safari. The existing WPT scope-selector.html (all browsers currently passing) cover querySelector[All] cases well for shadow roots, document, and other DocumentFragments. There should be no behavior change there. Fixed: 378698644 [1] w3c/csswg-drafts#11188 [2] w3c/csswg-drafts#7261 Change-Id: I1efbf999864a766ad5dfaee1fd67527309e38107

This special path causes :scope selectors to incorrectly match ':scope *' selectors in shadow roots, when it actually should match nothing [1]. The provided test scope-pseudo-in-shadow.html is passing in Firefox and Safari. The existing WPT scope-selector.html (all browsers currently passing) cover querySelector[All] cases well for shadow roots, document, and other DocumentFragments. There should be no behavior change there. Fixed: 378698644 [1] w3c/csswg-drafts#11188 [2] w3c/csswg-drafts#7261 Change-Id: I1efbf999864a766ad5dfaee1fd67527309e38107 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6011808 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/main@{#1382339}

…atchForRelation, a=testonly Automatic update from web-platform-tests Remove special :scope matching code in MatchForRelation This special path causes :scope selectors to incorrectly match ':scope *' selectors in shadow roots, when it actually should match nothing [1]. The provided test scope-pseudo-in-shadow.html is passing in Firefox and Safari. The existing WPT scope-selector.html (all browsers currently passing) cover querySelector[All] cases well for shadow roots, document, and other DocumentFragments. There should be no behavior change there. Fixed: 378698644 [1] w3c/csswg-drafts#11188 [2] w3c/csswg-drafts#7261 Change-Id: I1efbf999864a766ad5dfaee1fd67527309e38107 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6011808 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/main@{#1382339} -- wpt-commits: 7b7e2451a431d0cc68e4e5a96d19a71675dd782d wpt-pr: 49150

emilio added selectors-4 Current Work css-scoping-1 Current Work Agenda+ labels May 8, 2022

emilio removed the Agenda+ label May 10, 2022

emilio mentioned this issue May 11, 2022

Clean-up and fix :scope test. web-platform-tests/wpt#34032

Merged

emilio added a commit to emilio/web-platform-tests that referenced this issue May 11, 2022

Clean-up and fix :scope test.

908a043

As per discussion in w3c/csswg-drafts#7261

emilio added a commit to web-platform-tests/wpt that referenced this issue May 12, 2022

Clean-up and fix :scope test.

3bd0214

As per discussion in w3c/csswg-drafts#7261

emilio closed this as completed May 12, 2022

andruud reopened this Feb 16, 2023

andruud closed this as completed Feb 16, 2023

chromium-wpt-export-bot mentioned this issue Feb 21, 2023

[@scope] Support @scope (:host) web-platform-tests/wpt#38610

Merged

andruud mentioned this issue Aug 11, 2023

[css-scoping][css-cascade] :scope in shadowy prelude-less @scope matches nothing #9178

Closed

cgodo mentioned this issue Aug 3, 2024

fix(teleport): correctly select overlay container in shadow DOM vuetifyjs/vuetify#20277

Closed

andruud mentioned this issue Nov 12, 2024

[css-scoping] :scope > * matches nothing in shadow trees #11188

Closed

chromium-wpt-export-bot mentioned this issue Nov 13, 2024

Remove special :scope matching code in MatchForRelation web-platform-tests/wpt#49150

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-scoping] [selectors] :scope and DocumentFragment / ShadowRoot #7261

[css-scoping] [selectors] :scope and DocumentFragment / ShadowRoot #7261

emilio commented May 8, 2022

lifaon74 commented May 9, 2022

emilio commented May 9, 2022

lilles commented May 9, 2022

emilio commented May 9, 2022

lilles commented May 9, 2022

astearns commented May 9, 2022

emilio commented May 10, 2022

lilles commented May 10, 2022

emilio commented May 10, 2022

lilles commented May 10, 2022

lilles commented May 10, 2022

emilio commented May 11, 2022

andruud commented Feb 16, 2023

tabatkins commented Feb 16, 2023

tabatkins commented Feb 16, 2023 •

edited

Loading

andruud commented Feb 16, 2023

tabatkins commented Feb 16, 2023

lifaon74 commented Feb 18, 2023

andruud commented Aug 14, 2023

[css-scoping] [selectors] :scope and DocumentFragment / ShadowRoot #7261

[css-scoping] [selectors] :scope and DocumentFragment / ShadowRoot #7261

Comments

emilio commented May 8, 2022

lifaon74 commented May 9, 2022

emilio commented May 9, 2022

lilles commented May 9, 2022

emilio commented May 9, 2022

lilles commented May 9, 2022

astearns commented May 9, 2022

emilio commented May 10, 2022

lilles commented May 10, 2022

emilio commented May 10, 2022

lilles commented May 10, 2022

lilles commented May 10, 2022

emilio commented May 11, 2022

andruud commented Feb 16, 2023

tabatkins commented Feb 16, 2023

tabatkins commented Feb 16, 2023 • edited Loading

andruud commented Feb 16, 2023

tabatkins commented Feb 16, 2023

lifaon74 commented Feb 18, 2023

andruud commented Aug 14, 2023

tabatkins commented Feb 16, 2023 •

edited

Loading