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

[byung-woo]

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)

[bkardell]

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]

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]

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.

[css-meeting-bot]

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

[byung-woo]

Close this issue since the resolution have been applied: f6337dd

Thanks!