> Also, @robert, my solution supports the following notation, similar to
> yours but using the familiar jQuery syntax (before/after DOMReady):
> $.live("#mySelector", "click", fn1)
> .live("#mySelector", "mouseover", fn2)
> ...;
I understand the logic behind you wanting a $.live method (for the
edge cases where, presumably, you have hundreds or thousands of
elements that you're trying to match - and you don't want to run the
initial selector). Although there's a lot that I don't like about it:
- You are now passing in a selector to a non $(...) or .foo() method.
This goes against all the conventions that the library has - when you
interact with DOM elements, stay within the jQuery set.
- The only case where this matters is in a fringe case (namely, only
when you use both a complicated selector AND run it in IE < 8, since
all other browsers are using querySelectorAll) - but the existence of
the method in jQuery would remove the need to ever use the one method
that everyone should use.
- Presumably since you're in a situation where you're really caring
about performance - then why are you using .live to begin with?
Shouldn't you be binding lower in the document? This is why the
closest method was added, to make tasks like this even easier.
I would simply recommend: If you're in a situation where you're
starting with a critical number of elements on your page, enough to
ruin your pages' overall performance, then you should use a basic form
of event delegation, like so:
$("#someRootTable").click(function(e){
$(e.target).closest("td.foo").each(function(){
// Your code goes here.
});
});
Which is really what you should be doing anyway (live method or not).
--John
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
