Should preventDefault not be exposed on passive event handlers? #34
Comments
That would make event classes way too magical. |
Whoa, yeah we never do magic like that. If we wanted it to fail, throwing would be the way. |
I don't understand what you mean by magic in this context. Could you expand a bit? |
Changing what type of event object you get based on the options passed to the event listener registration. As Rick said, if we did want to enforce this more generally, we'd have |
Chrome 53.0.2745.0 canary for e.preventDefault returns native
Any backward compatibility for it? Old browsers will consider |
You need to feature detect. You can certainly use Modernizr to help you out. target.addEventListener(type, handler, Modernizr.passiveeventlisteners ? {passive:true} : false); |
Also note that |
Still, why not to list EventListener options in The best practice in any feature (new spec) is to handle backward compatibility, all polyfills and hacks must be avoided as much as possible. |
That would be a little weird because the Event would mutate over the dispatch. ie; think about adding two event listeners with different options and dispatch a single event to them. At each point of the dispatch of the single event the options would be different. If someone held onto the event and didn't explicitly copy it and did event delegation after some point they would see it mutate. |
I think this is a continuation of #3. I haven't seen this suggestion made for that problem.
The error message could be special-cased to add the reason why
e.preventDefault
is not a function.The text was updated successfully, but these errors were encountered: