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

> But yeah, for large trees having to check all ancestor nodes in an event's path while iterating through an event's path to find delegate listeners is either going to be slow or require complicated data structures.

The main performance issue is that iteratively testing selectors is linear with the number of installed delegated handlers. So yeah, you'd want to use a *complicated data structure* to make this more efficient. Luckily most of the hard work has already been done here by browser engines as they need theses structures for CSS rule set matching. Blink, Gecko and WebKit all use some sort of variation on a hash map or bloom filter for fast path testing. @github uses [this selector set implementation](https://github.com/josh/selector-set) for its batch selector testing.

> However, it only works for delegation done from document which is fine for their use case but not this one.

There's nothing `document` specific about the approach. That library just omitted delegation root configuration as @github rarely uses it. To implement it, each delegation root would manage their own selector list rather than hard coding it to the `document` itself.

> While going through the event path during the bubbling phase, also look at ancestor listeners that have "delegate" set and see if the specified selector matches the node in the event path.

I'd love to have this implementation. This would allow delegated handlers to use `stopPropagation` in a useful way that matches how directly bound event handlers would behave.

``` html
<a>
  <b>
    <c>
```

``` js
a.addEventListener('x', () => { log('a') })  
b.addEventListener('x', () => { log('b') })
a.addEventListener('x', (e) => { log('c'); e.stopPropagation() }, {delegate: 'c'})
```

1. Would only log `c`
2. Would log `b`, `a`, `c`

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

Received on Monday, 25 April 2016 19:56:48 UTC