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

Could/should the polyfill simply rewrite/extend addEventListener? #44

Closed patrickhlauke closed 6 years ago

patrickhlauke commented 8 years ago

Not sure if this is elegant or kosher, but...instead of defining a new addEventListenerWithOptions function, could/should the polyfill simply rewrite/extend/prollyfill addEventListener?

annevk commented 8 years ago

That usually ends up being problematic for extending the method in question further, no?

RByers commented 8 years ago

You mean the feature-detect logic in the explainer? Yeah I wasn't attempting to show a full polyfill here. It would be misleading to suggest that this code is a "polyfill" - it doesn't, for example, change the behavior of preventDefault.

In contrast, the polyfill we have checked into this repo DOES extend addEventListener.

patrickhlauke commented 8 years ago

Yes, it was the feature detect in the explainer...I thought that was the actual polyfill (hadn't checked the one in the repo). Maybe that section of the explainer needs a bit of prose to say something along the lines of "here's an example of how you can feature detect, using a custom addEventListenerWithOptions function - but in future, you should be able to do it with addEventListener once the proposed new syntax/feature lands...see also our polyfill..." or something?

Basically, just want to avoid confusion for devs who skim over the code and think that addEventListenerWithOptions will be the new syntax somehow...