Re: [csswg-drafts] [cascade-6] Unclear proximity for scoped descendant combinator (#8380)

> 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 follow 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)).



-- 
GitHub Notification of comment by andruud
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8380#issuecomment-1411921694 using your GitHub account


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

Received on Wednesday, 1 February 2023 11:42:17 UTC