Skip to main content

Bug Tracker

Side navigation

#249 closed feature (wontfix)

Opened October 05, 2006 06:04PM UTC

Closed March 24, 2007 03:21AM UTC

Last modified March 15, 2012 06:58PM UTC

Implement and test nextUntil (or similar)

Reported by: joern Owned by:
Priority: minor Milestone:
Component: core Version:
Keywords: Cc:
Blocked by: Blocking:

John's untested implementation:

$.fn.nextUntil = function(expr) {
var match = [];

var cur = this.nextSibling;
while ( cur && jQuery.filter( expr, [cur] ).r.length ) {
match = jQuery.merge( match, [ cur ] );
cur = cur.nextSibling;

return this.pushStack( match, arguments );
Attachments (0)
Change History (8)

Changed October 05, 2006 06:10PM UTC by joern comment:1

Take a definition list with multiple dts and dts as reference for testing.

Changed October 06, 2006 02:12AM UTC by brandon.aaro comment:2

Wouldn't this be better as a plugin?

Changed November 11, 2006 01:32PM UTC by joern comment:3

priority: majorminor
version: → 1.0
jQuery.fn.nextUntil = function(expr) {
    var match = [];

    // We need to figure out which elements to push onto the array
        // Traverse through the sibling nodes
        for( var i = this.nextSibling; i; i = i.nextSibling ) {
            // Make sure that we're only dealing with elements
            if ( i.nodeType != 1 ) continue;

            // If we find a match then we need to stop
            if ( jQuery.filter( expr, [i] ).r.length ) break;

            // Otherwise, add it on to the stack
            match.push( i );

    return this.pushStack( match, arguments );

This works and is extremly useful when selecting DOM elements. Adding to core is a double-edged sword: We don't want a bigger file size, but it's hard to find this when someone actually needs just this.

Changed November 17, 2006 10:06PM UTC by john comment:4

summary: Implement and test nextUntil (or similar)[DISCUSS] Implement and test nextUntil (or similar)
version: 1.0

While this plugin is quite useful - there are a number of advanced DOM-related functions that I'd like to write. In the end, however, they should probably remain out of core (otherwise, the size would explode). Stuff like:






  etc. etc.

Essentially, there should be functions that append to the return object (when they normally replace - see .add*) and there should be functions that return the result (when they normally only modify - see .getWrap*).

Obviously, all of these are useful in their own ways, but combined, it's pretty impractical to add them all into core. I'd like to try and get some feedback on this matter before closing the ticket.

Changed November 18, 2006 01:31AM UTC by john comment:5

priority: minorblocker

Changed November 20, 2006 08:30AM UTC by joern comment:6

By introducing the non-destructive behaviour, the add* methods wouldn't be necessary. Instead of:


you could simply combine existing methods:

var items = $(...);
items.add( items.nextUntil(...) );

Maybe something similar is possible for the get* methods. That would reduce the essential methods down to wrapAll(), wrapInner(), nextUntil() and prevUntil().

What is parentUntil() supposed to do? At first thought, it sounds like the same as parents(...).

Changed November 24, 2006 03:08PM UTC by john comment:7

priority: blockerminor
summary: [DISCUSS] Implement and test nextUntil (or similar)Implement and test nextUntil (or similar)

Ok, for now I think they should be broken off into a separate package, unless a really elegant way of handling them can be devised.

Changed March 24, 2007 03:21AM UTC by john comment:8

resolution: → wontfix
status: newclosed

Yeah - this is going to have to go in a separate plugin. I've got the meat of one kicking around. I'll polish it up and publish it.