[selectors-4] Remove the :scope dependency from the relative selectors definition #6399

byung-woo · 2021-06-21T15:31:56Z

Hello,

I'm currently prototyping the ':has' spec for chromium, and I landed a patch of supporting the child/next-sibling/subsequent-sibling relations some days ago.

While implementing the patch, I had to consider the various cases involving :scope in the :has argument, and came to the conclusion that the :scope dependency of the relative selector causes a lot of problems.

So, I'd like to ask opinions about removing the :scope dependency from the relative selectors definition.

As the grammar shows, the relative selector is the selector to begin syntactically with a combinator.

<relative-selector> = <combinator>? <complex-selector>

Similar with the complex selector, the relative selector represents a set of simultaneous conditions on a set of elements in the particular relationship described by its combinators. The only difference is that the relative selector can specify a relation to the reference element with the leftmost combinator.

To specify the reference element of the relative selector, the spec decided to use :scope.

Certain contexts may accept relative selectors, which are a shorthand for selectors that represent elements relative to a :scope element.

And it also specifies how to handle the :scope in the relative selector. (Absolutizing a Relative Selector)

The decision of using :scope for the reference element creates too much confusion especially with :has (:has seems to be the only selector that currently uses relative selector spec)

Below, I listed issues about :scope in :has. All the issues came from the :scope dependency in the relative selector. I think the :scope has its own purpose, and what relative selector need to have is a definition of its reference element. Using the `:scope' for the reference element of the relative selector looks problematic.

How about removing :scope dependency from the relative selector?
I think we can use the relative selector without absolutizing. Or we can use it after absolutized with a dummy pseudo(other than :scope) which represents reference element of the relative selector (And the dummy pseudo should be restricted to appear at the very beginning if it is allowed to use explicitly).

These are the issues from the :scope dependency.

1. Different behavior of :scope in :has

The :has spec tells that, :has evaluates the :scope in its argument selector as an element that the :has is representing.

It represents an element if any of the relative selectors, when absolutized and evaluated with the element as the :scope elements, would match at least one element.

This means that, when we have .a:has(> .b), it will be absolutized to .a:has(:scope > .b) internally before matching, and the :scope will be evaluated as .a element. Based on the :has definition, the two selectors .a:has(> .b) and .a:has(:scope > .b) are equivalent.

This behavior is changing the usual :scope usage.

The :scope in the style rule :scope > .b { color=blue; } will be :root. But the :scope in the js call main.querySelectorAll(':scope > .b') will be the main element.
The :scope in the style rule .a:has(:scope > .b) { color=blue; } will be the .a element, and the :scope in the js call main.querySelectorAll('.a:has(:scope > .b)') will be also .a element.

And there can be some confusing cases, like...

main.querySelectorAll('.a:has(~ .b:is(:scope .c)') -> :scope should be .a? or main?
.a:has(~ .b:is(:scope .c)) {...} -> :scope should be .a? or root?
main.querySelectorAll(':scope .a:has(:scope ~ .c)') -> The first :scope will be main but the second :scope will be .a
...

2. Explicit :scope in a :has argument can create complex cases.

Matching :has() on an element is basically heavy operation because it need to match its argument selector on its descendants.

For example, for .a:has(.b), all the descendants of .a need to match the argument selector .b to determine whether the .a element matches the :has(.b) selector or not. And when we have any .b element from descendants of .a, we can mark ancestors of the .b as a possible scope element of `:has(.b)'. With this, we can prevent repetitive argument matching operations for some cases.

But when a :scope is not leftmost (.a:has(.b :scope .c)) or it is compounded with other simple selectors (.a:has(.b:scope .c)), it is impossible or difficult to apply the optimization. The scope element of :has(.b:scope .c) must satisfy both .b and :has(c), and the scope element of :has(.b :scope .c) must satisfy both .b * and :has(.c).

The worst thing about ':has(.b :scope .c)' is that, it is same with :has(:is(.b *):scope .c). So the left side of the :scope in :has creates similar problems of :is in :has(actually worse) and the problems are really complex.

I think this issue is related with the responsibility of :has selector. What :has selector need to provide is selecting elements with ancestors or previous-sibling relations. But in those case, :has need to check the selected element, and need to check descendant/next-sibling relations from its upward. Instead of .a:has(.b .c:scope .d), using .b .a.c:has(.d) is more clear, intuitive and match the :has responsibility.

(Actually, the argument selector .b .c:scope .d is a concatenation of .b .c:scope and :scope .d(which means :has(.d)) and the first part doesn't need to be a part of the relative selector. This looks another issue)

3. Ambiguity of absolutizing a relative selector with :scope

The leftmost combinator of the relative selector differentiates itself from complex selector. And the leftmost combinator represents the relation to the reference element of the relative selector. To explicitly representing this, the ~ .a .b will be absolutized to :scope ~ .a .b before matching. But when we have ~ .a :scope .b, it will be absolutized to :scope ~ .a :scope .b which doesn't make sense and will never match.

Patch to show difference
To show the difference, I made a patch. By removing the :scope dependency, I can make the implementation more clear and simple (and optimal). But more importantly, I can remove tests for unnecessarily-arguable expressions such as:

.x:has(:scope ~ .a), :has(.x:scope ~ .a) -> .x:has(~ .a)
.x:has(.d ~ :scope ~ .e), :has(.d ~ .x:scope ~ .e) -> .d ~ .x:has(~ .e)

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

bkardell · 2021-06-23T19:31:20Z

Just wanted to add to this that I understand the complex history of where all of these things came from and why we got to what is in the spec today, but as we dig into the details, as @byung-woo explains - the ability for :has to have an 'implied' :scope when it is at the beginning and existing :scope support elsewhere makes for extremely complex to support (and very hard to read) cases. It seems reasonable to me to resolve this with a spec change that doesn't simply attempt to insert the existing :scope at the beginning.

css-meeting-bot · 2021-06-30T16:56:52Z

The CSS Working Group just discussed Remove the :scope dependency from the relative selectors definition.

The full IRC log of that discussion

<Rossen_> topic: Remove the :scope dependency from the relative selectors definition
<Rossen_> github: https://github.com//issues/6399
<TabAtkins> bkardell_: Selectors spec has :has(); we introduced a :scope pseudo alongside it. In qSA() it's very useful, but it's basically equivalent to :root in normal stylesheets.
<TabAtkins> bkardell_: Now :has() allows "relative selectors", starting with a combinator.
<TabAtkins> bkardell_: And :scope refers to that implicit starting element, and can be used later in the selector.
<TabAtkins> bkardell_: This causes a lot of issues; we'd prefer to drop the relative selector, and make the implicit starting element not be matched by :scope
<TabAtkins> bkardell_: I think current prior impl for it is only Prince. They do seem to support it.
<TabAtkins> bkardell_: But this is just a lot more difficult in the live profile
<TabAtkins> bkardell_: Issue goes into a lot more detail, looking for thoughts and feedback.
<TabAtkins> oriol: In most cases, when there's a selector inside of :has() that has :scope, you can refactor it to move that reference outside of the :has() and not lose any functionality
<leaverou_> +1 to whatever restrictions we need to place on :scope to make :has() happen

tabatkins · 2021-07-15T19:58:33Z

Dang, I had a comment I was in the middle of authoring, but I think I lost it when Chrome restarted to update.

Welp, in short: yeah I'm fine with removing :scope from :has(), and making relative selectors a more first-class concept that doesn't rely on :scope.

Support the relative selector grammar starting with combinator. - https://www.w3.org/TR/selectors-4/#typedef-relative-selector To simplify matching operation, some relation types are added. - kRelativeDescendant : Leftmost descendant combinator - kRelativeChild : Leftmost child combinator - kRelativeDirectAdjacent : Leftmost next-sibling combinator - kRelativeIndirectAdjacent : Leftmost subsequent-sibling combinator The ':scope' dependency in <relative-selector> definition creates too much confusion especially with ':has' as the CSSWG issue describes. - w3c/csswg-drafts#6399 1. ':scope' behavior in ':has' argument is different with usual ':scope' behavior. 2. Explicit ':scope' in a ':has' argument can create performance issues or increase complexity when the ':scope' is not leftmost or compounded with other simple selectors. 3. Absolutizing a relative selector with ':scope' doesn't make sense when the ':has' argument already has explicit ':scope' (e.g. ':has(~ .a :scope .b)' -> ':has(:scope ~ .a :scope .b)' To skip those complexity and ambiguity, this CL removed some logic related with the 'explicit :scope in :has argument', and added TODO comment to handle it later separately. As suggested in the CSSWG issue, this CL always absolutize the <relative-selector> with a dummy pseudo class. - kPseudoRelativeLeftmost The added pseudo class represents any elements that is at the relative position that matches with the leftmost combinator of the relative selector. This CL also includes tentative tests for some cases involving the ':scope' inside ':has' to show the result of the suggestion. By removing the ':scope' dependency from the relative selector, most of the ':scope' inside ':has' will be meaningless. (It will not match or can be changed more simple/efficient expression) Change-Id: I1e0ccf0c190d04b9636d86cb15e1bbb175b7cc30 Bug: 669058

Support the relative selector grammar starting with combinator. - https://www.w3.org/TR/selectors-4/#typedef-relative-selector To simplify matching operation, some relation types are added. - kRelativeDescendant : Leftmost descendant combinator - kRelativeChild : Leftmost child combinator - kRelativeDirectAdjacent : Leftmost next-sibling combinator - kRelativeIndirectAdjacent : Leftmost subsequent-sibling combinator The ':scope' dependency in <relative-selector> definition creates too much confusion especially with ':has' as the CSSWG issue describes. - w3c/csswg-drafts#6399 1. ':scope' behavior in ':has' argument is different with usual ':scope' behavior. 2. Explicit ':scope' in a ':has' argument can create performance issues or increase complexity when the ':scope' is not leftmost or compounded with other simple selectors. 3. Absolutizing a relative selector with ':scope' doesn't make sense when the ':has' argument already has explicit ':scope' (e.g. ':has(~ .a :scope .b)' -> ':has(:scope ~ .a :scope .b)' To skip those complexity and ambiguity, this CL removed some logic related with the 'explicit :scope in :has argument', and added TODO comment to handle it later separately. As suggested in the CSSWG issue, this CL always absolutize the <relative-selector> with a dummy pseudo class. - kPseudoRelativeLeftmost The added pseudo class represents any elements that is at the relative position that matches with the leftmost combinator of the relative selector. This CL also includes tentative tests for some cases involving the ':scope' inside ':has' to show the result of the suggestion. By removing the ':scope' dependency from the relative selector, most of the ':scope' inside ':has' will be meaningless. (It will not match or can be changed more simple/efficient expression) Change-Id: I1e0ccf0c190d04b9636d86cb15e1bbb175b7cc30 Bug: 669058 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2972189 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Byungwoo Lee <blee@igalia.com> Cr-Commit-Position: refs/heads/master@{#908421}

…:has tests, a=testonly Automatic update from web-platform-tests Support relative selector to update the :has tests Support the relative selector grammar starting with combinator. - https://www.w3.org/TR/selectors-4/#typedef-relative-selector To simplify matching operation, some relation types are added. - kRelativeDescendant : Leftmost descendant combinator - kRelativeChild : Leftmost child combinator - kRelativeDirectAdjacent : Leftmost next-sibling combinator - kRelativeIndirectAdjacent : Leftmost subsequent-sibling combinator The ':scope' dependency in <relative-selector> definition creates too much confusion especially with ':has' as the CSSWG issue describes. - w3c/csswg-drafts#6399 1. ':scope' behavior in ':has' argument is different with usual ':scope' behavior. 2. Explicit ':scope' in a ':has' argument can create performance issues or increase complexity when the ':scope' is not leftmost or compounded with other simple selectors. 3. Absolutizing a relative selector with ':scope' doesn't make sense when the ':has' argument already has explicit ':scope' (e.g. ':has(~ .a :scope .b)' -> ':has(:scope ~ .a :scope .b)' To skip those complexity and ambiguity, this CL removed some logic related with the 'explicit :scope in :has argument', and added TODO comment to handle it later separately. As suggested in the CSSWG issue, this CL always absolutize the <relative-selector> with a dummy pseudo class. - kPseudoRelativeLeftmost The added pseudo class represents any elements that is at the relative position that matches with the leftmost combinator of the relative selector. This CL also includes tentative tests for some cases involving the ':scope' inside ':has' to show the result of the suggestion. By removing the ':scope' dependency from the relative selector, most of the ':scope' inside ':has' will be meaningless. (It will not match or can be changed more simple/efficient expression) Change-Id: I1e0ccf0c190d04b9636d86cb15e1bbb175b7cc30 Bug: 669058 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2972189 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Byungwoo Lee <blee@igalia.com> Cr-Commit-Position: refs/heads/master@{#908421} -- wpt-commits: 5800374cbcad335de936e9a30868b2e5e5340a9d wpt-pr: 29718

css-meeting-bot · 2022-06-01T16:11:04Z

The CSS Working Group just discussed [selectors-4] Remove the :scope dependency from the relative selectors definition, and agreed to the following:

RESOLVED: Remove special handling of :scope in :has()
RESOLVED: Remove special handling of :scope in relative selectors generally

The full IRC log of that discussion

<fantasai> Topic: [selectors-4] Remove the :scope dependency from the relative selectors definition
<fantasai> github: https://github.com//issues/6399
<fantasai> futhark: :scope was specced to have a special meaning inside :has, that it matches the selector matched by :has() itself
<fantasai> futhark: It would be much simpler it kept the same meaning as it has outside of :has()
<TabAtkins> q+
<bkardell_> hi
<astearns> ack TabAtkins
<fantasai> TabAtkins: Making :has() give a special meaning to :scope wasn't a definitive choice, it just fell out of the definitions we had
<fantasai> TabAtkins: I'm comfortable with removing this
<bkardell_> what is the meeting link
<fantasai> TabAtkins: Just need to do some edits to definitions
<fantasai> futhark: there are complexities when it complexities for allowing :scope inside :has()
<fantasai> futhark: it'll be easier to handle cases wrt shadow hosts if we make this change
<TabAtkins> Yeah, :scope was invented for querySelector anyway, I'm comfortable boxing it off for just that purpose.
<fantasai> fantasai: I think to the extent we might need such a functionality, we can choose a different syntax for it
<emilio> +1
<fantasai> RESOLVED: Remove special handling of :scope in :has()
<fantasai> TabAtkins: I would prefer to remove it for relative selectors in general, and redefine :scope to just be for .querySelector
<fantasai> TabAtkins: I think we'll run into these problems in the future otherwise
<fantasai> RESOLVED: Remove special handling of :scope in relative selectors generally
<fantasai> futhark: issue 7211 looks related
<fantasai> astearns: Let's skip, I'll add a comment pointing to this resolution

Remove 'tentative' from has-argument-with-explicit-scope.tentative.html according to the issue resolution: - w3c/csswg-drafts#6399 - w3c/csswg-drafts#7211 Bug: 669058 Change-Id: Iae1946abfb4a5739e95f0b7d90869b6088f87b5b

Remove 'tentative' from has-argument-with-explicit-scope.tentative.html according to the issue resolution: - w3c/csswg-drafts#6399 - w3c/csswg-drafts#7211 Bug: 669058 Change-Id: Iae1946abfb4a5739e95f0b7d90869b6088f87b5b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3688773 Commit-Queue: Byungwoo Lee <blee@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1010508}

…licit :scope in :has(), a=testonly Automatic update from web-platform-tests Remove 'tentative' from wpt test for explicit :scope in :has() Remove 'tentative' from has-argument-with-explicit-scope.tentative.html according to the issue resolution: - w3c/csswg-drafts#6399 - w3c/csswg-drafts#7211 Bug: 669058 Change-Id: Iae1946abfb4a5739e95f0b7d90869b6088f87b5b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3688773 Commit-Queue: Byungwoo Lee <blee@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1010508} -- wpt-commits: 687d49f633cc46184dd2fcc18a34c04a15d0654c wpt-pr: 34298

byung-woo · 2022-06-21T07:45:47Z

Close this issue since the resolution have been applied: f6337dd

Thanks!

Support the relative selector grammar starting with combinator. - https://www.w3.org/TR/selectors-4/#typedef-relative-selector To simplify matching operation, some relation types are added. - kRelativeDescendant : Leftmost descendant combinator - kRelativeChild : Leftmost child combinator - kRelativeDirectAdjacent : Leftmost next-sibling combinator - kRelativeIndirectAdjacent : Leftmost subsequent-sibling combinator The ':scope' dependency in <relative-selector> definition creates too much confusion especially with ':has' as the CSSWG issue describes. - w3c/csswg-drafts#6399 1. ':scope' behavior in ':has' argument is different with usual ':scope' behavior. 2. Explicit ':scope' in a ':has' argument can create performance issues or increase complexity when the ':scope' is not leftmost or compounded with other simple selectors. 3. Absolutizing a relative selector with ':scope' doesn't make sense when the ':has' argument already has explicit ':scope' (e.g. ':has(~ .a :scope .b)' -> ':has(:scope ~ .a :scope .b)' To skip those complexity and ambiguity, this CL removed some logic related with the 'explicit :scope in :has argument', and added TODO comment to handle it later separately. As suggested in the CSSWG issue, this CL always absolutize the <relative-selector> with a dummy pseudo class. - kPseudoRelativeLeftmost The added pseudo class represents any elements that is at the relative position that matches with the leftmost combinator of the relative selector. This CL also includes tentative tests for some cases involving the ':scope' inside ':has' to show the result of the suggestion. By removing the ':scope' dependency from the relative selector, most of the ':scope' inside ':has' will be meaningless. (It will not match or can be changed more simple/efficient expression) Change-Id: I1e0ccf0c190d04b9636d86cb15e1bbb175b7cc30 Bug: 669058 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2972189 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Byungwoo Lee <blee@igalia.com> Cr-Commit-Position: refs/heads/master@{#908421} NOKEYCHECK=True GitOrigin-RevId: 4913bff09fee113fddaeef2aaeed95a527a1201a

Remove 'tentative' from has-argument-with-explicit-scope.tentative.html according to the issue resolution: - w3c/csswg-drafts#6399 - w3c/csswg-drafts#7211 Bug: 669058 Change-Id: Iae1946abfb4a5739e95f0b7d90869b6088f87b5b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3688773 Commit-Queue: Byungwoo Lee <blee@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1010508} NOKEYCHECK=True GitOrigin-RevId: 496f1a66e6f1f1d4af5f67839fcb94eda6f517cb

mrego added the selectors-4 Current Work label Jun 22, 2021

bkardell added the Agenda+ label Jun 30, 2021

atanassov removed the Agenda+ label Jun 30, 2021

chromium-wpt-export-bot mentioned this issue Jul 20, 2021

Support relative selector to update the :has tests web-platform-tests/wpt#29718

Merged

WebReflection mentioned this issue Jul 21, 2021

Add compatibility with some of ABP's script filters. uBlockOrigin/uBlock-issues#1011

Closed

8 tasks

This was referenced Apr 12, 2022

[selectors-4] Consider disallowing :scope inside :has() #7211

Closed

[selectors-4] Consider disallowing :host, :host(), :host-context() inside :has() #7212

Closed

emilio mentioned this issue May 16, 2022

[selectors] [css-conditional] Detecting :has() restrictions #7280

Closed

chrishtr added the Agenda+ label May 20, 2022

facelessuser mentioned this issue May 21, 2022

Tracking :scope issue related to relative selector lists (:has()) facelessuser/soupsieve#247

Closed

css-meeting-bot removed the Agenda+ label Jun 1, 2022

mozilla-apprentice mentioned this issue Jun 1, 2022

[selectors-4] Remove the :scope dependency from the relative selectors definition mozilla/wg-decisions#795

Open

tabatkins added a commit that referenced this issue Jun 2, 2022

[selectors-4] Untangle 'scoped' from 'relative'. #6399

f6337dd

chromium-wpt-export-bot mentioned this issue Jun 3, 2022

Remove 'tentative' from wpt test for explicit :scope in :has() web-platform-tests/wpt#34298

Merged

byung-woo closed this as completed Jun 21, 2022

Loirooriol added the Closed Accepted by CSSWG Resolution label Jun 21, 2022

tabatkins mentioned this issue Feb 16, 2023

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

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[selectors-4] Remove the :scope dependency from the relative selectors definition #6399

[selectors-4] Remove the :scope dependency from the relative selectors definition #6399

byung-woo commented Jun 21, 2021 •

edited

bkardell commented Jun 23, 2021

css-meeting-bot commented Jun 30, 2021

tabatkins commented Jul 15, 2021

css-meeting-bot commented Jun 1, 2022

byung-woo commented Jun 21, 2022

[selectors-4] Remove the :scope dependency from the relative selectors definition #6399

[selectors-4] Remove the :scope dependency from the relative selectors definition #6399

Comments

byung-woo commented Jun 21, 2021 • edited

bkardell commented Jun 23, 2021

css-meeting-bot commented Jun 30, 2021

tabatkins commented Jul 15, 2021

css-meeting-bot commented Jun 1, 2022

byung-woo commented Jun 21, 2022

byung-woo commented Jun 21, 2021 •

edited