[cascade-6] Unclear proximity for scoped descendant combinator

[andruud]

This combinator [>>] differs from the descendant combinator in that it applies weak scoping proximity to the relationship between A and B.

In simple cases (e.g. A >> B), it's clear what this means, but what about more complex cases? A >> B >> ... >> Z, A:has(B >> C), :is, :not?

It doesn't seem easy to spec an easily understandable behavior for >> given the amount of flexibility we have in selectors. Perhaps we should revisit whether >> really is needed at all.

If we do keep it, we should avoid introducing complexity that would be detrimental to performance:

• Avoid a variable number of cascade criteria. Proximity should be a single number for the whole declaration.
• Avoid a proximity value which depends on multiple successful matches of the same selector. (E.g. imagine an :is(X,Y) which matches for both X and Y but with different proximities). Once we find a match, we can not continue looking for "better" matches.

Note: The proposed selector scoping notation does not have any of these issues, so perhaps we should continue to explore that direction instead, if we really want "inline" scoping.

[Loirooriol]

Yeah, it kinda sounds like the specificity problem from #1027. Example:

.a ~~ .b >> .c {}

<div class="a" id="a1"></div>
<div class="b" id="b1">
  <div class="a" id="a2"></div>
  <div></div><div></div><div></div><div></div><div></div><div></div>
  <div class="b" id="b2">
    <div class="c"></div>
  </div>
</div>

If we match .b as #b2, then .a must match #a2, which means ~~ has 7 hops, and >> has 1 hop.
If we match .b as #b1, then .a must match #a1, which means ~~ has 1 hops, and >> has 2 hops.

The 2nd option seems better, but this means that, in order to know the precedence of a selector, it can't just be matched greedily, all possible matchings need to be considered.

[mirisuzanne]

@andruud Can you clarify why the other scope notations don't have this issue? Is it just a clearer order of operations - matching scope root/boundary elements, and then resolving each selector in relation to those defined scopes?

I think it's likely we'd want to go with the more clear syntax if they have the same meaning, but just as a way of understanding the issue – does it help to parse a b >> c >> d as sugar for @scope (a b) { @scope (c) { d { ... }}}, and what all would that impact?

[tabatkins]

Right, my understanding of the intention of the scoping combinators is that they're functionally sugar for a set of (possibly nested) @scope elements, just letting you express certain relationships more compactly when you're not using the scope root multiple times. @scope should be strictly more powerful, so any question one can have about scoping combinators should be answerable by just asking it about @scope instead.

[andruud]

The 2nd option seems better, but this means that, in order to know the precedence of a selector, it can't just be matched greedily, all possible matchings need to be considered.

Thanks for that context and info @Loirooriol. Not being able to finish selector matching at the first match is pretty much unacceptable. (Though maybe this problem is only possible to create if we add ~~ at the moment)?

Can you clarify why the other scope notations don't have this issue?

Nested @scope always follows the pattern A >> B >> C >> ... etc, but with selectors you can get much more creative (e.g. use different combinators between some compounds), and that is where I don't understand how proximity is supposed to be calculated.

@scope should be strictly more powerful, so any question one can have about scoping combinators should be answerable by just asking it about @scope instead.

OK, if >> is intended as sugar for (nested) @scope, that's fair enough, but then I still need to understand how to actually desugar, or at least how to calculate proximity. How do I desugar the following?

1. A >> :not(B >> C) >> D
2. A >> B C >> D
3. A >> :is(B C) >> D (I know how desugar this, but adding it to highlight that it's not the same as (2)).

[mirisuzanne]

If we do with plain 'syntax sugar', I think you would basically treat each mention of >> as a nesting of scopes. That probably answers the question for examples 2 and 3, but not for example 1 – because there is no logic for @scope to exist inside a pseudo-class, and so no clear way to desugar it. The others, I would expect to be:

2. A >> B C >> D -> @scope (A) { @scope (B C) { D }
3. A >> :is(B C) >> D -> @scope (A) { @scope (:is(B C)) { D } (I think in practice, the scope-start parameter already acts like :is(), so this might be redundant)

To highlight the two questions raised here:

Nesting Scopes, Generally:

To make sure I understand what's implemented: When @scope rules are nested, you're not currently calculating all the proximity relationships up the chain - only the final relationship. You get a single number by asking: 'how close is the final matched element to the nearest scope root?' Since scopes can only contract, never expand, we know that the nearest @scope rule will give us the nearest scope root as well.

I think that might be a reasonable solution, and certainly the easiest one to reason about. If we wanted, I think there might be ways to expand that and give some priority to things that are 'scoped more often' – but I'm not sure that's helpful, or actually captures a useful heuristic. But that probably needs more clarity in the specification.

Sugaring Limits:

It seems like the other issue here is that a scope-start clause in the @scope rule has some limitations that a normal combinator does not: you can't put @scope inside a pseudo-class, for example. In order for the syntax sugar to be a strict subset of the @scope feature, it would also have to be disallowed in those situations. I think we could make that limitation on either the old selector syntax or the combinators – but both have a chance of adding confusion (especially when combined with nesting).

(I'd be tempted to drop any scope selector sugar from v1 of the spec, and return later to see if it's necessary)

[Loirooriol]

how close is the final matched element to the nearest scope root?

I still don't think that's clear.

@sibling-scope (.a) {
  @scope (.b) {
    .c { color: blue }
  }
}

<div class="a"></div>
<div class="b" id="b1">
  <div class="b" id="b2">
    <div class="c"></div>
  </div>
</div>

Does it mean that the rule will not apply, since the closest .b has no .a previous sibling?
Does it mean that the rule will apply, matching .b as #b1, but for the number of >> hops we use #b2? Do we also count the number of ~~ hops from #b2 (NaN?) ?

[andruud]

@mirisuzanne My point with (2) vs (3) was that they can not both expand to effectively the same @scope chain (as you have done), because they do not select the same elements.

A >> B C >> D -> @scope (A) { @scope (B C) { D }

For example, the @scope chain would match B -> A -> C -> D, but the selector would not.

The @scope chain would also match B -> ACD (where ACD is an element that can be matched by either A or C or D) since scoping is root-inclusive. (Although that's a separate point).

To make sure I understand what's implemented: When @scope rules are nested, you're not currently calculating all the proximity relationships up the chain - only the final relationship.

Yes, exactly. I did not see anything in https://drafts.csswg.org/css-cascade-6/#scope-atrule that would suggest anything else.

I think that might be a reasonable solution, and certainly the easiest one to reason about.

It should be completely uncontroversial in terms of performance, and if it's easy to reason about I guess that's something authors will appreciate as well. The question is if it's "too simple" from the author's perspective, i.e. would proximity still be useful enough in more complicated (nested) scoping scenarios? (I can't answer this question).

[andruud]

@Loirooriol Using the "nearest scope is what determines proximity" mode, I suppose your example would go like this:

• A sibling scope is created at .a.
• @scope (.b) only produces scopes for elements that are siblings of .a, so we get a scope at #b1 and no scope at #b2.
• The proximity of .c is the distance to the nearest enclosing scope (#b1), i.e. 2.

(Unless I've misunderstood how @sibling-scope should work).

[mirisuzanne]

That's how I would parse the example as well. Nested scope-start rules are (according to spec already) scoped by any parent scope rules. So #b2 is never matched by any scope rule in that example.

For example, the @scope chain would match B -> A -> C -> D, but the selector would not.

Right. Yeah, that's a more difficult logic to impose on a combinator.

The question is if it's "too simple" from the author's perspective, i.e. would proximity still be useful enough in more complicated (nested) scoping scenarios? (I can't answer this question).

In my mind proximity is a useful heuristic in the simple cases - and this logic continues to handle those cases well. Once things get more complicated, authors will likely need to think about other cascade controls: layers, specificity, etc. With a heuristic like this, I think it would be a mistake to get too clever about solving more complex scenarios in an abstract or magical way.

[tabatkins]

I mean, the equivalent @scope was just written incorrectly. The actual desugaring of A >> B C >> D is:

@scope (A) {
  @scope (:scope B C) {
    :scope D {...}
  }
}

That does match the identical set of elements.

The only significant thing is the fact that you can write something like A :is(B >> C) D, which can't be desugared into a @scope. We can just disallow that and only allow >> at the top level of a selector.

[andruud]

@tabatkins 👍

Then how about the following:

• Add Tab's desugaring above to the spec, as an example.
• Specify that >> is only allowed top-level in the selector.
• Remove selector scoping notation from the spec.
• Specify that proximity is a single number derived from the innermost relationship only. (I read @mirisuzanne's comment above as favoring this approach at the moment).

[mirisuzanne]

We've already resolved to remove the selector scoping notation - so don't need to do anything there, except apply the changes. I like this proposed resolution. Add to telecon or async agenda?

[tabatkins]

Don't necessarily need a resolution at all - the spec is FPWD. As long as it's not expected to be controversial (and from this thread, it shouldn't be), you can just do it.