feature request: .preimage

[gibson042]

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.

[ajpiano]

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!

[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.

[rwaldron]

-1, Feature creep

[dmethvin]

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

[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.

[jzaefferer]

-1, Too much special-case.

[jaubourg]

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

[dmethvin]

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

[mikesherov]

-1, gets us further away from qSa, when we should be moving more towards it.

[timmywil]

-1

[rwaldron]

-1, Feature creep

[gibson042]

I was pointed to  http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1454.html by timmywil, and in light of the similarities between this feature request and Element.matches(selector, reference), I'd like to redirect this one towards jQuery.fn.is(selector, reference) (as noted by Lachlan in the message, there is a basic equivalence between the two methods except for ours missing the latter signature).

I still think preimage functionality is useful, and is probably a dependency anyway, but the description of this ticket is no longer completely accurate. Should it be updated, or replaced?

[gibson042]

#11124 resolves the bulk of this ticket. The remainder is essentially blocked by #11109.

[dmethvin]

Voted off the island.