Re: [whatwg/dom] Event delegation via EventListenerOptions (#215)

> Interesting. That snippet seems to set delegateTarget to event.currentTarget (the callback this value) and currentTarget to the object you're most likely interested in. Would it not make more sense to name them the other way around? We could even change the callback this value to match currentTarget since the filtering will happen before the listener is invoked. Not entirely sure what's most desirable.

Not saying I prefer it, but these are the semantics jQuery uses.

I'd say there logic is that they wanted `this` to be the element that matched the selector since thats the most commonly used target. And it followed if `this` was the matched element, then `this === currentTarget`.

Similarly, if you direct bind the handler, the matched target is your current target.

``` js
document.querySelector('.foo').addEventListener('click', function() {
  // is a .foo
})

obj.addEventListener('click', function() {
  this // is a .foo
}, { matches: ".foo" })
```

I've pretty much never used `delegateTarget` in my own code. But its mostly there for completeness to known the actual element the event handler to bound too.

>  We'd still offer ignoreBubbles as a standalone primitive so you implement your own delegate if you're not happy with Selectors and want XPath or some such.

👍 My "delegated xpath events" lib is going to be so popular someday!

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/215#issuecomment-208976758

Received on Tuesday, 12 April 2016 15:54:56 UTC