Bug Tracker

Opened 16 years ago

Closed 16 years ago

Last modified 11 years ago

#249 closed feature (wontfix)

Implement and test nextUntil (or similar)

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

Description

http://jquery.com/discuss/2006-August/010451/

John's untested implementation:

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

this.each(function(){
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 );
};

Change History (8)

comment:1 Changed 16 years ago by joern

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

comment:2 Changed 16 years ago by brandon.aaro

Wouldn't this be better as a plugin?

comment:3 Changed 16 years ago by joern

Priority: majorminor
Version: 1.0
jQuery.fn.nextUntil = function(expr) {
    var match = [];

    // We need to figure out which elements to push onto the array
    this.each(function(){
        // 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.

comment:4 Changed 16 years ago by john

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:

  .wrapAll()
  .wrapInner()

  .getWrap()
  .getWrapAll()
  .getWrapInner()

  .nextUntil()
  .prevUntil()
  .parentUntil()

  .allAfter()
  .allBefore()

  .addNext()
  .addPrev()
  .addParent()
  .addParents()
  .addFind()

  .addNextUntil()
  .addPrevUntil()
  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.

comment:5 Changed 16 years ago by john

Priority: minorblocker

comment:6 Changed 16 years ago by joern

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

$(...).addNextUntil(...);

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

comment:7 Changed 16 years ago by john

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.

comment:8 Changed 16 years ago by john

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.

Note: See TracTickets for help on using tickets.