- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 28 Jul 2014 14:43:10 -0400
- To: Marat Tanalin <mtanalin@yandex.ru>, "www-dom@w3.org" <www-dom@w3.org>
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