- From: Domenic Denicola <d@domenic.me>
- Date: Sat, 11 Jul 2015 18:19:04 +0000
- To: Anne van Kesteren <annevk@annevk.nl>, Rick Byers <rbyers@chromium.org>
- Cc: "olli@pettay.fi" <olli@pettay.fi>, Tim Dresser <tdresser@chromium.org>, WHATWG <whatwg@whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, Dave Tapuska <dtapuska@chromium.org>, Jonas Sicking <jonas@sicking.cc>
From: Anne van Kesteren [mailto:annevk@annevk.nl] >> 2) Should mayCancel=false listeners always get an Event with >> cancelable=false, or is this "just a hint" such that all listeners >> still get the same event with the same properties. >> https://github.com/RByers/EventListenerOptions/issues/2 > > I was thinking that this basically sets a flag used during the invocation of the listener that makes preventDefault() a no-op (or > throw?) for that listener. But it would not affect other listeners or the Event object. The user agent could then make an optimization if no "traditional" listener was added. This makes the most sense; I agree. Having a single addEventListener call change a property of the Event itself would be strange. However, I'm unsure exactly how this would work, especially in terms of deltas to the DOM spec. If it works as Anne describes above, you could still do `setTimeout(() => e.preventDefault(), 0)`, which would be outside the invocation of that listener and thus would presumably bypass any this-listener-may-not-cancel protections. I'm not sure that actually matters though, since canceling inside setTimeout(,0) shouldn't have much affect besides changing `e.defaultPrevented`. So maybe it's OK.
Received on Saturday, 11 July 2015 18:19:34 UTC