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.
andruud
commented
1 year ago
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:
: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.