Re: Adding an interface to provide a list of listeners

On 7/28/14, 2:07 PM, Marat Tanalin wrote:
> If an application removes listeners, then the application probably needs it. Doesn't it?

Doubtful, actually.

> Note that removal of all listeners at once is already achievable _anyway_ -- just with a somewhat dumb method (replacing original element with its clone).

You just assumed all event targets are elements.  They're not.

> By "all listeners" I mean all listeners that are removed by replacing an element with its clone.

There's that assumption again.

> I.e., I mean listeners that exist from web-developer's perspective, not from implementor's perspective.

These perspectives overlap.  How would you characterize a listener added 
by a browser extension that is "removed" when cloning due to a bug in 
the extension?

>      * a browser's extension that overrides a handler
>        of the browser's built-in element like button. For example,
>        in my UsableHomeButton extension I override the `onclick`
>        property of the Home button. But if original browser listeners
>        have been binded via `addEventListener()` instead of `onclick`
>        property, I would then be forced to use cloning method,
>        otherwise I couldn't remove original listeners at all;

If this is really the behavior you want, you can use a capturing 
listener and stopPropagation, right?

But yes, event groups (akin to CSS cascade levels) might be nice.  We 
used to have them in the spec, then they got dropped because of the 
complexity.

-Boris

Received on Monday, 28 July 2014 18:43:40 UTC