Ticket #11483 (closed enhancement: plugin)
"current" context for add
| Reported by: | gibson042 | Owned by: | gibson042 |
|---|---|---|---|
| Priority: | undecided | Milestone: | None |
| Component: | unfiled | Version: | 1.7.1 |
| Keywords: | Cc: | ||
| Blocking: | Blocked by: |
Description
add is the only traversing method that does not use "current set" as the context for selector arguments. It has a context parameter, but $set.add( selector, context ) is identical to $set.add( $( selector, context ) ) and requires breaking the chain for intermediate variable assignment.
We should special-case context=true to enable code like $setAndNext = $set.add( "+ *", true ) or $form.add(".invalid").
Change History
comment:3 Changed 14 months ago by dmethvin
It won't close since it's not "pending". It's worth discussion.
comment:4 Changed 14 months ago by dmethvin
- Owner set to gibson042
- Status changed from new to pending
We've had some discussion about relative selectors, which always end up going through Sizzle's JavaScript path. Where would this feature simplify code? Are there some real-life examples?
comment:5 Changed 14 months ago by gibson042
- Status changed from pending to new
Good comments.
Regarding relative selectors, I doubt this enhancement would much increase their use, because anyone wanting to use $set.add( strRelative, true ) is probably already using $set.add( selRelative, $set ) or $set.find( selRelative ).andSelf(). But as an aside, isn't @timmywil's big Sizzle overhaul going to seriously improve the Javascript path for scoped queries anyway?
On to examples. .and and its derivative .andSelf seem to be fairly uncommon, but this new syntax would clarify many uses of the former (by eliminating otherwise unnecessary variable declarations) and most of the latter (by avoiding clunky re-adding).
- http://api.jquery.com/andSelf/: $("div").find("p").andSelf().addClass("border") → $("div").add( "p", true ).addClass("border")
- https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.18/jquery-ui.js: uiDialogTitlebar.find("*").add(uiDialogTitlebar).disableSelection() → uiDialogTitlebar.add( "*", true ).disableSelection()
- http://stackoverflow.com/questions/3037382/jquery-this-selector-help; http://stackoverflow.com/questions/2828019/looking-for-jquery-find-method-that-includes-the-current-node: $set.find(selector).andSelf() → $set.add( selector, true )
- http://forum.jquery.com/topic/advanced-use-of-load-function; http://jsfiddle.net/2g8Yv/8/: $set.filter(selector).add( $set.find(selector) ) → $set.filter( selector ).add( selector, true )
comment:6 Changed 14 months ago by dmethvin
To me, the use of .andSelf() (perhaps renamed to .addPrior() per #9800) is much clearer than using a second Boolean argument to .add(). Admittedly it's not as mystical as .stop(true, true) but the added method name makes it much clearer what is going on.
comment:7 Changed 14 months ago by gibson042
I agree, and in my opinion we'd be better off if this were the default context for .add( selector ) rather than null (document), but that would be a breaking change.
Can you come up with a better special-case value (null and undefined are probably out, as are strings and user-defined objects—but perhaps a conveniently-mapped true like like jQuery.CONTEXT_SELF?) or (*shudder*) new method name, or is this ticket doomed to rejection by historical contingency?
comment:8 Changed 14 months ago by dmethvin
- Status changed from new to closed
- Resolution set to plugin
I think it makes more sense to do this with .addPrior() or an .addFind(selector) plugin at this point, I'm not a fan at all of a magical second argument. If history were rewritten I agree it might make sense to have .add() use the set elements as context, since it's so easy to add rooted elements via $(). Perhaps we can add a time machine to the 1.9 roadmap.
Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

Err, that second example should be $form.add( ".invalid", true ).