We've discussed your ticket and we feel it might be of benefit to not return undefined here. Rather if it were to return a jQuery object with nothing that would probably make more sense. In terms of the other areas this applies to, we may also need to update .find(), .filter() and .not() as well.

Marking your ticket as valid from that perspective for further discussion/comments before we decide to actually change behavior.

.find returns an empty selection for any invalid argument. The small change to filter and not is included in this pull request:

https://github.com/jquery/jquery/pull/206

Here's some proof for find: http://jsfiddle.net/timmywil/YDbUu/

Confirmed with timmywil that .find() currently already returns an empty selection and does so for .find('')[an empty string] or .find(' ')[nothing but whitespace in a string].

With respect to the changes for .filter() and .not() these are currently in a pull request that has been linked back to this ticket just for reference.

We'll be closing this ticket now given that there is nothing more to be done here. Thanks!

I'm terribly sorry, I made a big error in my ticket title and text. My problem is NOT primarily with .find() but with .filter(). Calling foo.filter(' ') - that is, with a space as parameter - gives DIFFERENT results on FF and e.g. Chrome. Please run my example, and you'll see!

(I guess that it's also interesting to think about related functions such as .find() in this context, of course. And in any case, the behaviour of all these functions should be standardized and documented.)

What should filters such as null, "" and " " return? Perhaps that should be regarded as "no filter", and therefore return all elements?

So please consider re-opening this ticket. The problem is actually with .filter() which IS behaving weird in 1.5.1.

What should filters such as null, "" and " " return?

This seems like a garbage-in, garbage-out situation to me. I don't think we want to firmly specify the behavior of all invalid inputs and then be bound to make bad input work that way forevermore. There is a definite cost to making jQuery check all inputs.

I don't think we want to firmly specify the behavior of all invalid inputs [...]

The official documentation should - at least - provide a strict definition what is valid input, and what is NOT valid input. And that the result of invalid input (however that turns out to be defined) is undefined.

Otherwise, users will start to guess and presume. That will result in brittle code and ultimately badwill for jQuery.

I had to spend a whole week to find a bug in a package written by someone who - it turned out - had presumed things about .filter().

Dave, actually we already do for pretty much every jquery function and its even shorter than checking for null because it's just <pre>!arg</pre>. Its already been fixed in the pull request and it was just a matter of adding one word. I'm surprised we weren't already doing this for filter and not, because we really do have it for just about every other function. And like I said, it's super easy. Not all inputs tho. Just the falsey ones when they make no sense to jquery.

A .filter(" ") (a single space) won't meet the !arg test. Were we trying to fix that?

I disagree on specifying what is NOT valid input. Other than bad selectors being invalid input.

No I agree we don't need to worry about that one. Sizzle handles that for us anyway.

Replying to [comment:8 dmethvin]:

I disagree on specifying what is NOT valid input. Other than bad selectors being invalid input.

You have a point here; a a complete list of all possible invalid inputs can be made very long indeed.

As log as there's a strict definition of what IS valid input, then logically everything else is NOT. And -important!- a note that the result for invalid input is UNDEFINED.

Actually this was landed and fixed - and will be in 1.6.