It just doesn't make sense to use a child or sibling selector in a is() function. is() is dealing with a single element, it's a waste of resources to go back and look if it's inside something when you should have done that in the selector.
I think returning true for complex selectores is a safety measure. It's better to skip it then lose all elements because of a bad selector. - ricardo On Oct 2, 9:06 pm, Dave Methvin <[EMAIL PROTECTED]> wrote: > > 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.
