Skip to content
This repository has been archived by the owner on Mar 19, 2018. It is now read-only.

Consider new names for addEventListener and removeEventListener #18

Closed
RByers opened this issue Jul 9, 2015 · 5 comments
Closed

Consider new names for addEventListener and removeEventListener #18

RByers opened this issue Jul 9, 2015 · 5 comments

Comments

@RByers
Copy link
Member

RByers commented Jul 9, 2015

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
Copy link
Member Author

RByers commented Jul 9, 2015

@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
Copy link
Collaborator

annevk commented Jul 10, 2015

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
Copy link
Member Author

RByers commented Jul 10, 2015

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
Copy link
Collaborator

annevk commented Jul 11, 2015

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
Copy link
Member Author

RByers commented Jul 11, 2015

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" [email protected]
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)
.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants