You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Simple matchers are simple - known complexity. Filters are potentially substantially more complex. It makes sense to avoid calling them when possible. There are cases where filters are included as part of a compound selector[1] in which the simple selectors are leading. In this case it is functionally equivalent, but potentially much faster to test the filter only if the other simple selectors don't match. I explained this more on the forum[2], but, that's the gist and I don't know that anyone is actively watching this. I implemented and tested this in my fork[3] and it seems good, but I don't want to send a pull or think about taking it further without some feedback.
Simple matchers are simple - known complexity. Filters are potentially substantially more complex. It makes sense to avoid calling them when possible. There are cases where filters are included as part of a compound selector[1] in which the simple selectors are leading. In this case it is functionally equivalent, but potentially much faster to test the filter only if the other simple selectors don't match. I explained this more on the forum[2], but, that's the gist and I don't know that anyone is actively watching this. I implemented and tested this in my fork[3] and it seems good, but I don't want to send a pull or think about taking it further without some feedback.
[1] http://dev.w3.org/csswg/selectors4/#compound
[2] http://forum.jquery.com/topic/matchers-and-pseudos
[3] https://github.com/bkardell/sizzle/blob/master/src/sizzle.js#L1749
The text was updated successfully, but these errors were encountered: