Side navigation
#11540 closed bug (plugin)
Opened March 31, 2012 09:32AM UTC
Closed April 02, 2012 02:49PM UTC
Last modified October 15, 2012 07:18PM UTC
.next() different from .nextAll().eq(0)
| Reported by: | anonymous | Owned by: | anonymous |
|---|---|---|---|
| Priority: | undecided | Milestone: | None |
| Component: | unfiled | Version: | 1.7.2 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
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).
Attachments (0)
Change History (6)
Changed March 31, 2012 12:59PM UTC by comment:1
| _comment0: | 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]]. → 1333198952888942 |
|---|---|
| owner: | → anonymous |
| status: | new → pending |
Changed April 02, 2012 01:18PM UTC by comment:2
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?
Changed April 02, 2012 02:49PM UTC by comment:3
| keywords: | → needsdocs |
|---|---|
| resolution: | → plugin |
| status: | pending → closed |
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.
Changed April 05, 2012 06:06AM UTC by comment:4
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?
Changed April 05, 2012 02:43PM UTC by comment:5
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.
Changed October 15, 2012 07:18PM UTC by comment:6
| keywords: | needsdocs |
|---|
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: