Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Sat, Jul 11, 2015 at 11:41 PM, Rick Byers wrote: > What Anne describes is perfect! I'm not hung up on the value of cancelable > itself - some internal bit on Event that makes preventDefault a no-op (or > event throw) during listener invocation is fine with me (and I agree - less > weird). If code really wants to test whether it's call to preventDefault > took effect, it can check defaultPrevented afterward. No, that is not what I said. I said we'd disable preventDefault() for the listeners that have this bit set. If all listeners for a given event have the bit said, the UA can make the optimization. (And the setTimeout() example is perfectly deterministic. It changes the canceled flag, but after that flag has been consulted by the dispatcher.) -- https://annevankesteren.nl/
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
[On vacation now with only a phone - so apologies for the brevity and top-posting] What Anne describes is perfect! I'm not hung up on the value of cancelable itself - some internal bit on Event that makes preventDefault a no-op (or event throw) during listener invocation is fine with me (and I agree - less weird). If code really wants to test whether it's call to preventDefault took effect, it can check defaultPrevented afterward. I'm also not worried about the setTimeout example. Calls to preventDefault after dispatch is done have no effect, so at best such code was already unpredictable (probably always a no-op already). Rick On Jul 11, 2015 3:14 PM, "Anne van Kesteren" wrote: > On Sat, Jul 11, 2015 at 8:19 PM, Domenic Denicola wrote: > > 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. > > It's fine. The code that dispatches an event and then checks the > event's canceled flag will run before a task queued by invoking > setTimeout() during dispatching runs. You can only change course if > you change the canceled flag during dispatch (which this new way of > listening would prevent). > > > -- > https://annevankesteren.nl/ >
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Sat, Jul 11, 2015 at 8:19 PM, Domenic Denicola wrote: > 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. It's fine. The code that dispatches an event and then checks the event's canceled flag will run before a task queued by invoking setTimeout() during dispatching runs. You can only change course if you change the canceled flag during dispatch (which this new way of listening would prevent). -- https://annevankesteren.nl/
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
From: Anne van Kesteren [mailto:ann...@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.
Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour wrote: > Minor bikeshed: > I have put scrollRestoration on history.options instead of directly history > itself in order to use history.options as an interface to contain any other > restoration related attributes which have similar semantics (e.g., recorder > scroll position, scale restoration, recorded scale). Is the History object Document-bound in all implementations? Otherwise adding new dependent objects will be problematic security-wise. Also, History isn't that full and can easily contain a bunch of properties. What's the use of a new object, can you use it independently somehow? -- https://annevankesteren.nl/
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Fri, Jul 10, 2015 at 9:12 PM, Rick Byers wrote: > 1) Should we extend the existing addEventListener API or change the API > names (and perhaps other things) completely. > https://github.com/RByers/EventListenerOptions/issues/18 It seems most other "DOM peers" are okay with overloading the third argument. I can settle on that if that moves things along faster. > 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. -- https://annevankesteren.nl/
