Consider new names for addEventListener and removeEventListener

[RByers]

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]

@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]

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]

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]

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]

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
#18 (comment)
.