.next() different from .nextAll().eq(0)

[anonymous]

jQuery version tested: 1.4 to 1.7.2

Browser: several including Firefox 11 and Chrom 19

Sample code:

var textNode = $('<div><a id="0">0</a>1<a id="2">2</a><a id="3">3</a><a id="3">4</a></div>').contents().eq(1);
console.log(textNode.nextAll().eq(0));
console.log(textNode.next());

Result:

[<a id=​"2">​2​</a>​]
[<a id=​"3">​3​</a>​]

Now, I know .next() and .nextAll() are both supposed to work with element node only, but jQuery does allow them to be called on text nodes (as opposed to raising an exception). The return value of .nextAll() is as expected, but the one of .next() is not. As long as .next() does return something, it should be the same as .nextAll().eq(0).

[dmethvin]

So are you asking for text-node test cases to be added to our unit tests? That seems like a lot of work for an edge case. I'd prefer to just add a more explicit note to .contents() Something like this:

Warning: many jQuery methods do not expect collections that contain text nodes, and may not behave predictably with them. The .filter() method always removes text nodes in a collection. List of specifically allowed operations?.

[henrypijames]

Well, I'd like traversing to work with text nodes. But in case jQuery team chooses not to support that, it must do more to prevent ambiguity. Common logic dictates that .next() return the same value as .nextAll().eq(0), and those functions are so straight forward that it's unrealistic to expect developers to RTFM to understand the problem.

Also, given "many jQuery methods do not expect collections that contain text nodes", what should developers use instead to deal with trees containing text nodes?

[dmethvin]

it must do more to prevent ambiguity

This must not be very ambiguous to most people, we don't get a lot of confusion about it. That's why I think docs may be the best path.

what should developers use instead to deal with trees containing text nodes?

The tree itself will contain text nodes, obviously. The question is whether the jQuery collection of nodes should contain text nodes. Generally it doesn't unless you try hard with methods like .contents().

It isn't like we made up these rules out of thin air; CSS selectors only target elements and not text nodes. Google will find plenty of solutions for handling these cases including plugins, but you could write a new one if the existing solutions aren't satisfactory.

[henrypijames]

For the foreseeable future, can I count on the behavior of .nextAll() to remain stably the way it should be and has been so far?

[gibson042]

Yes. If anything changes as a result of this ticket, it will be jQuery( textNode ).next() returning the same thing as jQuery( textNode.nextSibling ) for text nodes that are followed by elements.