search

WICG / EventListenerOptions

An extension to the DOM event pattern to allow authors to disable support for preventDefault
Other
1.17k stars 140 forks source link

Consider new names for addEventListener and removeEventListener #18

Closed RByers closed 8 years ago

RByers commented 8 years ago

If we had completely new method names, it would make feature detection simpler (possibly addressing #16). Also people aren't in love with "addEventListener", maybe now is a good time to change?

@annevk suggests just on and off.

RByers commented 8 years ago

@domenic says:

I tend to disagree. I think we shouldn't "use up" the nice names like off and on without significant thought as to what a well-designed better-EventTarget would look like. And I think that such thought would take time and motivation which we should not block this proposal on.

The idea of extending addEventListener seems like the most reasonable thing to me. If someone wants to take on the larger project of EventTarget overhaul, that should be done in a more deliberate fashion.

annevk commented 8 years ago

Well, on/off have had some amount of thought and design put into them, but I don't know what the timeline for this new thing is.

RByers commented 8 years ago

We've got some aggressive goals in chromium to make measurable progress on the event-handler jank problem this quarter (i.e. shipping in chromium 46 or 47). In particular we see this as a big issue in emerging markets where low power devices are only becoming more popular. But you probably shouldn't need to care about our goals here - just trying to explain the urgency from my perspective.

annevk commented 8 years ago

Since nobody in (@domenic, @bzbarsky, @smaug----) seemed concerned, I guess it'd be okay with the third argument overload and postponing the more major changes and renaming.

What would help me if the proposal was instead done as a set of changes to the algorithms in the DOM Standard. Currently the implications to the processing model are rather vague.

RByers commented 8 years ago

Great! I can take a crack at a pull request for that when I'm back (~2 weeks). I'm sure I'll need your expertise to really get it right, but I can at least do the first pass. On Jul 11, 2015 1:41 PM, "Anne van Kesteren" notifications@github.com wrote:

Since nobody in (@domenic https://github.com/domenic, @bzbarsky https://github.com/bzbarsky, @smaug---- https://github.com/smaug----) seemed concerned, I guess it'd be okay with the third argument overload and postponing the more major changes.

What would help me if the proposal was instead done as a set of changes to the algorithms in the DOM Standard. Currently the implications to the processing model are rather vague.

— Reply to this email directly or view it on GitHub https://github.com/RByers/EventListenerOptions/issues/18#issuecomment-120647651 .