bindWithEvent is deprecated but you can do that with just bind and passing the element as well.
What you and Tim are describing (the 'this' vs event.target thing) is what I was using a while ago. I kept using event.target and used an additional check/function to find the 'correct' element I needed to apply changes to (usually like the parent LI of some A element, or maybe go back to the parent LI from some SPAN that was in an A, lol).. then I was 100% I always had the right element. In the end I think it was just too much code and a waste of ms. On May 4, 8:39 pm, Izzy <[email protected]> wrote: > then use this.clickHandler.bindWithEvent(this, $(element).get('id')); > > and modify the clickHandler signature to function(event, id) > > you can get at the original element with $(id). > > you would just want to not pass in the element to the bind, or you > might as well have just done an inner function, pass the id through > and you can safely retrieve the element you need. > > if it doesn't have an id, give it one: $(element).set('id', 'element_' > + $(element).uid); > > it would also be feasible to create a custom binding solution for > these type situations (maybe i'll do that). :) > > On May 4, 11:55 am, Tim Wienk <[email protected]> wrote: > > > > > Izzy, > > > Using event.target may not work as intended when clicking child > > elements of the element you attached the event > > to:http://jsfiddle.net/timwienk/hNMm4/ > > > In the event handler `this` refers to the element the event fired on. > > event.target is the element that was the event's target. > > > (Sometimes this actually *is* the intended effect, and it's actually > > the basis of how delegation works. Attach an event to a parent > > element, but only do stuff when `event.target.match(yourSelector)`).
