Bug Tracker

Opened 8 years ago

Last modified 8 years ago

#10868 closed feature

feature request: .preimage — at Version 9

Reported by: gibson042 Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.7.1
Keywords: Cc:
Blocked by: Blocking:

Description (last modified by dmethvin)

I'd like a method that reverses the normal direction of selectors, used to find elements for which a .find with given selector would return the context element(s).

Sample usage:

function childDelegate( $element, selClickTarget, strEvents, fnHandler ) {
  return $( $element ).on( strEvents, selClickTarget, function() {
    if ( $( this ).preimage( "> " + selClickTarget, $element ) ) {
      return fn.apply(this, arguments);
    }
  });
}

childDelegate( $dl, "dt ~ dd > a:first-child", "click", function( evt ) {
  alert( "child dd clicked" );
});

Proposed signature: .preimage( selector [, candidates] )

The one-argument version returns a jQuery object containing all elements from which the results of .find(selector) would include a member of the context set.

The two-argument version is a short-circuiting alias for .preimage( selector ).is( candidates ), returning a boolean indicating intersection between the full results and a candidate set.

Implementation would add helper functions on the Sizzle relative operators (e.g., $.each({'>': $.fn.parent, '+': $.fn.prev, '~': $.fn.prevAll}, function(operator,fn){ try{$.expr.relative[operator].preimage=fn;}catch(x){} });) and a relatively simple function to parse/chunk selectors and incrementally build up the result set by working backwards through them.

A link to a working demonstration will be posted shortly.

Change History (9)

comment:1 Changed 8 years ago by ajpiano

Keywords: 1.8-discuss added

If you could give us a few details about the usecase for such a function as well, we'd really appreciate it. Is this meant to be an internal improvement to Sizzle? A user-facing API? Thanks!

comment:2 Changed 8 years ago by gibson042

It'd be a documented external API, but might ultimately have the potential to shrink Sizzle and/or jQuery codebases through internal use. Mostly, I want it to provide intuitive event handling for potentially-nesting widgets (#6696; #10762; etc.). It'll be valuable if we ever decide to support .on(events, ">...", fn), and will let jQuery users simulate support for it now.

The closure provided by reverse lookups shouldn't add much code weight, and has the potential to enable a lot of currently-unpredictable creative applications.

comment:3 Changed 8 years ago by Rick Waldron

-1, Feature creep

comment:4 Changed 8 years ago by dmethvin

-1, I have no idea what this is, which makes me think I am against it.

comment:5 Changed 8 years ago by dmethvin

Status: newopen

comment:6 Changed 8 years ago by gibson042

Plugin implementing request: http://plugins.jquery.com/project/preimage

Working example: http://jsbin.com/usabam

Uncompressed, and including unit tests and functionality backporting to support jQuery 1.4+ instead of 1.6+, the plugin is 5.88 KiB. If brought into jQuery proper, access to local variables and functions would eliminate redundancy and result in no more than a 100-200 byte initial increase in jquery.min.js, decreased if .preimage can be used to optimize existing functionality.

comment:7 Changed 8 years ago by jzaefferer

Description: modified (diff)

-1, Too much special-case.

comment:8 Changed 8 years ago by jaubourg

-1, I'd like to see a plugin first in order to assess usefulness.

comment:9 Changed 8 years ago by dmethvin

Description: modified (diff)

-1, The code was lost in the Great Depluginization Purge; I'd still like to see it but if it's 100-200 bytes it doesn't seem like it would land. Of course, you worked miracles with the undefined patch so maybe I should wait to see it.

Note: See TracTickets for help on using tickets.