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: |
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 ); };
Attachments (0)
Change History (8)
Changed October 05, 2006 06:10PM UTC by comment:1
Changed October 06, 2006 02:12AM UTC by comment:2
Wouldn't this be better as a plugin?
Changed November 11, 2006 01:32PM UTC by comment:3
priority: | major → minor |
---|---|
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.
Changed November 17, 2006 10:06PM UTC by 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:
.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.
Changed November 18, 2006 01:31AM UTC by comment:5
priority: | minor → blocker |
---|
Changed November 20, 2006 08:30AM UTC by comment:6
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(...).
Changed November 24, 2006 03:08PM UTC by comment:7
priority: | blocker → minor |
---|---|
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 comment:8
resolution: | → wontfix |
---|---|
status: | new → closed |
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.
Take a definition list with multiple dts and dts as reference for testing.