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

andruud has just created a new issue for https://github.com/w3c/csswg-drafts:

== [cascade-6] Unclear proximity for scoped descendant combinator ==
> This combinator [[>>](https://drafts.csswg.org/css-cascade-6/#scope-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](https://drafts.csswg.org/css-cascade-6/#selector-scoping) does not have any of these issues, so perhaps we should continue to explore that direction instead, if we really want "inline" scoping.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8380 using your GitHub account


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

Received on Tuesday, 31 January 2023 11:19:00 UTC