find() with a :not selector does not have "scoped" behavior

[Pointy]

Description

A .find() call like $(x).find(".foo button") will only find button elements that have a parent with class "foo" somewhere in the DOM subtree under element x. That is the jQuery intention.

However, a .find() call like $(x).find(":not(.foo button)") will find all elements that are not a button descending from an element with class "foo". However, that descendant test is not scoped to the subtree under element x. If any element from x up to the root of the DOM has class "foo", buttons will be excluded from the result.

This may be intentional or preserved for legacy reasons. I have not personally suffered from this, the bug is mostly to have something to reference.

Link to test case

https://codepen.io/Pointy/pen/OJwWyMb?editors=1111

[mgol]

I think this is intentional. For regular tokens, e.g. classes, appending .foo to #a .b > .c means we start from the elements with the class c that match the selector and filter out ones that don't have the foo class. :not() contents have different semantics as they speak about the context. It makes sense to me that this means the selector in :not() is evaluated globally.

But I'll add a team discussion label to get this through the team.

[Pointy]

Thank you, so you're saying that :not(a b) is effectively :not(:root a b). As I said, I don't have a strong opinion, so I'm perfectly happy with whatever is decided, and in future Stack Overflow questions I can link to this issue.

[mgol]

so you're saying that :not(a b) is effectively :not(:root a b)

Not exactly because :not(html) is not equivalent to :not(:root html) - the latter would not exclude anything. But yes, I'd expect the selector passed to :not() to be a global one.

[timmywil]

Thanks for your issue. We discussed in the meeting and I think it's okay that :not is global here. It's always worked that way and we don't like to diverge from the spec when we don't have to.