> Is there a reason, internally, why it would always return > true instead of false?
I agree it's not consistent, I'm not sure about why. Then again it's outside the domain of documented valid inputs. It would probably be better to just say the result is undefined for those cases so it could be handled differently later without guilt for breaking existing code. > Or, preferably, if it's a complex selector evaluate it globally, then > check to see if the item to be matched is contained within the > results. The .is() acts on the selected elements, just like .filter(). You could extend .filter() to allow global selectors and only return the intersection of two sets, which *would* be cool. However, I'm not sure what rules it would apply to know when to use global vs selected- element context. It seems like you'd have to start processing the selector assuming you were filtering the current context, then back up and start all over again with a global context and do an intersection of two sets if a complex selector was detected.
