[cascade-6] Unclear proximity for scoped descendant combinator · Issue #8380 · w3c/csswg-drafts (original) (raw)

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.