Bug Tracker


Ticket #11540 (closed bug: plugin)

Opened 2 years ago

Last modified 18 months ago

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

Reported by: anonymous Owned by: anonymous
Priority: undecided Milestone: None
Component: unfiled Version: 1.7.2
Keywords: Cc:
Blocking: Blocked by:


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);


[<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).

Change History

comment:1 Changed 2 years ago by dmethvin

  • Owner set to anonymous
  • Status changed from new to pending

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?.

Version 0, edited 2 years ago by dmethvin (next)

comment:2 Changed 2 years ago by 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?

comment:3 Changed 2 years ago by dmethvin

  • Keywords needsdocs added
  • Status changed from pending to closed
  • Resolution set to plugin

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.

comment:4 Changed 2 years ago by 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?

comment:5 Changed 2 years ago by 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.

comment:6 Changed 18 months ago by mikesherov

  • Keywords needsdocs removed

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.


Add a comment

Modify Ticket

as closed

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.