Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 3:44 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 9:39 AM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 9:05 AM, James Ross w3c-20040...@james-ross.co.uk
wrote:
Date: Thu, 9 Jul 2015 14:42:07 +0200
From: phil...@opera.com
I think this looks like a very promising approach. Would there be any
way to feature detect support for EventListenerOptions as the third
argument? It seems like a problem that addEventListener(type,
callback, { mayCancel: false }) would be treated as
addEventListener(type, callback, true) in existing browsers.
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#extensions-to-the-event-interface
and
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#examples
example 2 are intended to cover this.
Right, thanks. What I've suggested is kind of weird though. Olli raises
a good point that we should discuss general dictionary-member feature
detection patterns in the abstract before committing to something like this.
I'd love other opinions / ideas on the bug.
I should perhaps add that I'd hope developers don't really need to use the
pattern in example #2 explicitly. Instead I expect they'd mostly rely on a
simple polyfill (which I'll take an initial crack at writing once the API
shape settles down a bit).
I see, the answer is getSupportedListenerOptions(). Seems slightly
peculiar, but would work. Should be on EventTarget if anything,
though.
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers rby...@chromium.org wrote: I think there's a big opportunity to substantially improve scroll performance on the web in the relatively short term by doing something incremental. I.e. I'm pretty sure I can get major scroll-blocking libraries like Google Analytics to opt into the pattern proposed here in a relatively short timeframe. I'm much less sure I could get them to switch to a completely new event API in any sort of reasonable timeframe. Either way they need to branch their code, no? What do you think about an incremental path? I don't see any fundamental reason that things need to change drastically. Overloading a boolean argument with a dictionary seems bad. And if we are to have a new API anyway, we might as well pick the better names. If we can get consensus on the basic approach, then I'd be happy to rework my proposal in the form of a pull-request and move all issue tracking to whatwg/dom. There's probably no point in doing that until we have an agreement on the basic API shape, right? Fair. -- https://annevankesteren.nl/
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 9:49 AM, Philip Jägenstedt phil...@opera.com wrote:
On Thu, Jul 9, 2015 at 3:44 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 9:39 AM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 9:05 AM, James Ross
w3c-20040...@james-ross.co.uk
wrote:
Date: Thu, 9 Jul 2015 14:42:07 +0200
From: phil...@opera.com
I think this looks like a very promising approach. Would there be any
way to feature detect support for EventListenerOptions as the third
argument? It seems like a problem that addEventListener(type,
callback, { mayCancel: false }) would be treated as
addEventListener(type, callback, true) in existing browsers.
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#extensions-to-the-event-interface
and
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#examples
example 2 are intended to cover this.
Right, thanks. What I've suggested is kind of weird though. Olli
raises
a good point that we should discuss general dictionary-member feature
detection patterns in the abstract before committing to something like
this.
I'd love other opinions / ideas on the bug.
I should perhaps add that I'd hope developers don't really need to use
the
pattern in example #2 explicitly. Instead I expect they'd mostly rely
on a
simple polyfill (which I'll take an initial crack at writing once the API
shape settles down a bit).
I see, the answer is getSupportedListenerOptions(). Seems slightly
peculiar, but would work. Should be on EventTarget if anything,
though.
Added that suggestion to the bug:
https://github.com/RByers/EventListenerOptions/issues/16#issuecomment-119983345.
I agree it's peculiar - I'd love to hear other ideas!
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 3:58 PM, Rick Byers rby...@chromium.org wrote: I'd love to hear other ideas! Well, we have had some discussions in the past about introducing a better event API: https://gist.github.com/annevk/5238964 Maybe the time has come... (I agree with Philip that if we add this it would need to become part of whatwg/dom. That seems like a better place for any GitHub discussion too.) -- https://annevankesteren.nl/
Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Mon, Jul 6, 2015 at 2:47 AM, Mike West mk...@google.com wrote: I've dropped the opener/openee-disowning behavior from my proposal, and renamed the sandboxing keyword to `allow-popups-to-escape-sandbox` in https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvmentsdiff=9958oldid=9955 It appears that this new keyword as described would still require the use of allow-popups in addition to allow-popups-to-escape-sandbox. Since it doesn't make any sense on its own can you change it so that either keyword allows popups to happen? That it, propose changing [Set] The sandboxed auxiliary navigation browsing context flag https://developers.whatwg.org/origin-0.html#sandboxed-auxiliary-navigation-browsing-context-flag, unless tokens contains the allow-popups keyword. to [Set] The sandboxed auxiliary navigation browsing context flag https://developers.whatwg.org/origin-0.html#sandboxed-auxiliary-navigation-browsing-context-flag, unless tokens contains the allow-popups or *allow-popups-to-escape-sandbox* keyword. (might then require changing -to-escape- to -that-escape-) You question to bz was can you live with it, and I can live with it. I wish it could be shorter, but my attempts (allow-popups-unsandboxed or allow-unsandboxed-popups) weren't much shorter. Keeping allow popups in there is good, especially if it can be used in place of regular allow-popups. using the word sandbox is better than anything about auxiliary contexts. - Dan Veditz
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 11:22 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers rby...@chromium.org wrote: I think there's a big opportunity to substantially improve scroll performance on the web in the relatively short term by doing something incremental. I.e. I'm pretty sure I can get major scroll-blocking libraries like Google Analytics to opt into the pattern proposed here in a relatively short timeframe. I'm much less sure I could get them to switch to a completely new event API in any sort of reasonable timeframe. Either way they need to branch their code, no? Yeah, but the way it's defined now it's 2 small lines of extra JS for them: http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2 We've also already got a lot of support for this incremental approach from some IE and Mozilla folks (I've reached out to Safari folks privately, but nothing public yet). I probably should have reached out to this list long ago - sorry about that (I was mainly focused from the input scenario side, for quite awhile it was looking like we'd prefer a CSS API instead of something like this). That said, I like the look of your proposal (though not sure what exactly filter and marker would do). If you think it's something that's practical accomplish in a reasonable time frame then I'm all for it. Is it fully polyfillable? I just don't think this tiny tweak should be the thing that necessitates such a major API change. What do you think about an incremental path? I don't see any fundamental reason that things need to change drastically. Overloading a boolean argument with a dictionary seems bad. And if we are to have a new API anyway, we might as well pick the better names. We could just add a 4th argument for now (a dictionary or even just a boolean) if you think that's better to keep the changes absolutely minimal until this larger rework can be done. If we can get consensus on the basic approach, then I'd be happy to rework my proposal in the form of a pull-request and move all issue tracking to whatwg/dom. There's probably no point in doing that until we have an agreement on the basic API shape, right? Fair. -- https://annevankesteren.nl/
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 11:05 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jul 9, 2015 at 3:58 PM, Rick Byers rby...@chromium.org wrote: I'd love to hear other ideas! Well, we have had some discussions in the past about introducing a better event API: https://gist.github.com/annevk/5238964 Maybe the time has come... I think there's a big opportunity to substantially improve scroll performance on the web in the relatively short term by doing something incremental. I.e. I'm pretty sure I can get major scroll-blocking libraries like Google Analytics to opt into the pattern proposed here in a relatively short timeframe. I'm much less sure I could get them to switch to a completely new event API in any sort of reasonable timeframe. What do you think about an incremental path? I don't see any fundamental reason that things need to change drastically. (I agree with Philip that if we add this it would need to become part of whatwg/dom. That seems like a better place for any GitHub discussion too.) If we can get consensus on the basic approach, then I'd be happy to rework my proposal in the form of a pull-request and move all issue tracking to whatwg/dom. There's probably no point in doing that until we have an agreement on the basic API shape, right? -- https://annevankesteren.nl/
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On 07/09/2015 06:22 PM, Anne van Kesteren wrote: On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers rby...@chromium.org wrote: I think there's a big opportunity to substantially improve scroll performance on the web in the relatively short term by doing something incremental. I.e. I'm pretty sure I can get major scroll-blocking libraries like Google Analytics to opt into the pattern proposed here in a relatively short timeframe. I'm much less sure I could get them to switch to a completely new event API in any sort of reasonable timeframe. Either way they need to branch their code, no? What do you think about an incremental path? I don't see any fundamental reason that things need to change drastically. Overloading a boolean argument with a dictionary seems bad. And if we are to have a new API anyway, we might as well pick the better names. I'm a bit worried that figuring out what the new better API might take quite a bit more time than adding something to the existing one. There is https://github.com/RByers/EventListenerOptions/issues/12 open for the proposed API change, if we want to be more careful with backwards compatibility. If we can get consensus on the basic approach, then I'd be happy to rework my proposal in the form of a pull-request and move all issue tracking to whatwg/dom. There's probably no point in doing that until we have an agreement on the basic API shape, right? Fair.
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 6:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/9/15 8:42 AM, Philip Jägenstedt wrote: Would there be any way to feature detect support for EventListenerOptions as the third argument? Yes. You call addEventListener and pass an object that has getters for the properties you care about detecting. If those getters get invoked, the browser knows about those dictionary properties. Ah, that's cool :) Philip
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 11:40 AM, Philip Jägenstedt phil...@opera.com wrote: On Thu, Jul 9, 2015 at 5:30 PM, Rick Byers rby...@chromium.org wrote: On Thu, Jul 9, 2015 at 11:22 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers rby...@chromium.org wrote: I think there's a big opportunity to substantially improve scroll performance on the web in the relatively short term by doing something incremental. I.e. I'm pretty sure I can get major scroll-blocking libraries like Google Analytics to opt into the pattern proposed here in a relatively short timeframe. I'm much less sure I could get them to switch to a completely new event API in any sort of reasonable timeframe. Either way they need to branch their code, no? Yeah, but the way it's defined now it's 2 small lines of extra JS for them: http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2 We've also already got a lot of support for this incremental approach from some IE and Mozilla folks (I've reached out to Safari folks privately, but nothing public yet). I probably should have reached out to this list long ago - sorry about that (I was mainly focused from the input scenario side, for quite awhile it was looking like we'd prefer a CSS API instead of something like this). That said, I like the look of your proposal (though not sure what exactly filter and marker would do). If you think it's something that's practical accomplish in a reasonable time frame then I'm all for it. Is it fully polyfillable? I just don't think this tiny tweak should be the thing that necessitates such a major API change. What do you think about an incremental path? I don't see any fundamental reason that things need to change drastically. Overloading a boolean argument with a dictionary seems bad. And if we are to have a new API anyway, we might as well pick the better names. We could just add a 4th argument for now (a dictionary or even just a boolean) if you think that's better to keep the changes absolutely minimal until this larger rework can be done. How about if we just pick nice and short names with a dictionary as one of the arguments, but initially limit these new APIs to exactly the existing behavior plus the mayCancel bit? We can tackle other nice-to-haves later, unless there's some default behavior of the existing APIs that would be worth changing at the same time? That seems like a nice incremental compromise. Using a new name for addEventListener will help address some of the feature detection / compatiblity concerns too. Filed https://github.com/RByers/EventListenerOptions/issues/18. Speaking of that, having a new function makes it an option to let mayCancel be false by default, compat-wise at least. That's a good question regardless of which approach we take. Filed https://github.com/RByers/EventListenerOptions/issues/17 Philip
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On 7/9/15 8:42 AM, Philip Jägenstedt wrote: Would there be any way to feature detect support for EventListenerOptions as the third argument? Yes. You call addEventListener and pass an object that has getters for the properties you care about detecting. If those getters get invoked, the browser knows about those dictionary properties. Also, I think that this would make good sense as part of DOM itself, This spec requires changes to DOM anyway, because the spec as written is not valid IDL: It's creating two overloads that can both be called with two arguments. So we'll need to remove the optional annotation from the boolean arg that's already in DOM when we add this new overload. That doesn't seem like a problem. -Boris
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 12:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/9/15 8:42 AM, Philip Jägenstedt wrote: Would there be any way to feature detect support for EventListenerOptions as the third argument? Yes. You call addEventListener and pass an object that has getters for the properties you care about detecting. If those getters get invoked, the browser knows about those dictionary properties. Ah, perfect - I hadn't thought of that! Thanks! I'll change the spec for that now (https://github.com/RByers/EventListenerOptions/issues/16). Also, I think that this would make good sense as part of DOM itself, This spec requires changes to DOM anyway, because the spec as written is not valid IDL: It's creating two overloads that can both be called with two arguments. So we'll need to remove the optional annotation from the boolean arg that's already in DOM when we add this new overload. That doesn't seem like a problem. Yeah, plus there's the whole interaction with the 'capture' variable (spec should probably talk about a single 'options' variable with members like 'capture' every place it refers to the 'capture' variable).. I knew I'd never be able to spec it properly on it's own, just enough to get the point across clearly.
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 5:30 PM, Rick Byers rby...@chromium.org wrote: On Thu, Jul 9, 2015 at 11:22 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers rby...@chromium.org wrote: I think there's a big opportunity to substantially improve scroll performance on the web in the relatively short term by doing something incremental. I.e. I'm pretty sure I can get major scroll-blocking libraries like Google Analytics to opt into the pattern proposed here in a relatively short timeframe. I'm much less sure I could get them to switch to a completely new event API in any sort of reasonable timeframe. Either way they need to branch their code, no? Yeah, but the way it's defined now it's 2 small lines of extra JS for them: http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2 We've also already got a lot of support for this incremental approach from some IE and Mozilla folks (I've reached out to Safari folks privately, but nothing public yet). I probably should have reached out to this list long ago - sorry about that (I was mainly focused from the input scenario side, for quite awhile it was looking like we'd prefer a CSS API instead of something like this). That said, I like the look of your proposal (though not sure what exactly filter and marker would do). If you think it's something that's practical accomplish in a reasonable time frame then I'm all for it. Is it fully polyfillable? I just don't think this tiny tweak should be the thing that necessitates such a major API change. What do you think about an incremental path? I don't see any fundamental reason that things need to change drastically. Overloading a boolean argument with a dictionary seems bad. And if we are to have a new API anyway, we might as well pick the better names. We could just add a 4th argument for now (a dictionary or even just a boolean) if you think that's better to keep the changes absolutely minimal until this larger rework can be done. How about if we just pick nice and short names with a dictionary as one of the arguments, but initially limit these new APIs to exactly the existing behavior plus the mayCancel bit? We can tackle other nice-to-haves later, unless there's some default behavior of the existing APIs that would be worth changing at the same time? Speaking of that, having a new function makes it an option to let mayCancel be false by default, compat-wise at least. Philip
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Rick Byers That seems like a nice incremental compromise. Using a new name for addEventListener will help address some of the feature detection / compatiblity concerns too. Filed https://github.com/RByers/EventListenerOptions/issues/18. 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.
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 2:21 PM, Jonas Sicking jo...@sicking.cc wrote: Speaking of that, having a new function makes it an option to let mayCancel be false by default, compat-wise at least. That's a good question regardless of which approach we take. Filed https://github.com/RByers/EventListenerOptions/issues/17 I definitely think that if we're going to have any chance of moving significant portions of the web to have better performance, we need things to be fast by default, and then opt-in to slower behavior. And the more we can simply point to these APIs are fast, use these, those APIs are slow, don't use those the better. It should be very clear when you're falling off the fast path. I agree 100% with this principle. Changed mayCancel to default to false: https://github.com/RByers/EventListenerOptions/commit/b6ca043c9f13cea773a9338d580a0ebc24ea8140 . This raises a related question though - is the 'mayCancel' name strong enough to indicate performance implications to developers? I personally still kind of like the 'blocksScroll' design instead: https://github.com/RByers/EventListenerOptions/issues/14 / Jonas
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 2:57 PM, Rick Byers rby...@chromium.org wrote: On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/9/15 1:32 PM, Rick Byers wrote: Done. How does example 2 look now? http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2 Looks like it would work. Also looks kind of ugly because of the object-truthiness bit, but I'm not sure there's any way to avoid that while keeping the overload a boolean and dictionary setup. I'm not a fan of this approach. It'll be very hard to get users to opt in consistently to the faster behavior. Especially given that it requires much more typing. Bigger picture, we're seriously exploring in chromium taking both a carrot and stick approach to the event-handler jank problem. Carrots are this new API, better devtools tooling highlighting the problem, etc. Sticks are more controversial so we're not ready to propose anything concrete yet. But imagine if particularly slow sites that haven't opted out of blocking handlers got some sort of unresponsive UI notification ( http://crbug.com/504904). The window-greying-out behavior introduced in Windows Vista had a very strong impact on developers motivation to invest in UI-thread responsiveness :-). Also Google search results already take page load time into account ( http://googlewebmastercentral.blogspot.ca/2010/04/using-site-speed-in-web-search-ranking.html), if we could reliably collect scroll jank performance I don't see why that also wouldn't be a good signal to use in search rankings (though this is only my personal opinion - no inside knowledge here at all). Anyway, suffice it to say that I fully agree we can't expect big wins in practice just by shipping this new API (no matter how simple we make it, though the simpler the better of course). But I'm still confident that having an API like this will open a lot of doors that together will lead to substantial user-experience improvements on the web. I think this probably depends on your position on the 'should mayCancel=false be enforced' debate: https://github.com/RByers/EventListenerOptions/issues/2 If you (like me) believe it's important to keep mayCancel=false listeners from being able to cancel their events, then developers need to type a fair bit more than just what this example shows for proper testing. Really they need to use a small polyfill. If they're already depending on the polyfill for Event.cancelable/preventDefault behavior, than what's a few more lines for slightly more complex feature detection? To make this more concrete I can start whipping up a concrete polyfill and tests. But I was hoping to settle the key design question in #2 first. / Jonas
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/9/15 1:32 PM, Rick Byers wrote: Done. How does example 2 look now? http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2 Looks like it would work. Also looks kind of ugly because of the object-truthiness bit, but I'm not sure there's any way to avoid that while keeping the overload a boolean and dictionary setup. I'm not a fan of this approach. It'll be very hard to get users to opt in consistently to the faster behavior. Especially given that it requires much more typing. I think this probably depends on your position on the 'should mayCancel=false be enforced' debate: https://github.com/RByers/EventListenerOptions/issues/2 If you (like me) believe it's important to keep mayCancel=false listeners from being able to cancel their events, then developers need to type a fair bit more than just what this example shows for proper testing. Really they need to use a small polyfill. If they're already depending on the polyfill for Event.cancelable/preventDefault behavior, than what's a few more lines for slightly more complex feature detection? To make this more concrete I can start whipping up a concrete polyfill and tests. But I was hoping to settle the key design question in #2 first. / Jonas
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 12:47 PM, Rick Byers rby...@chromium.org wrote: On Thu, Jul 9, 2015 at 12:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/9/15 8:42 AM, Philip Jägenstedt wrote: Would there be any way to feature detect support for EventListenerOptions as the third argument? Yes. You call addEventListener and pass an object that has getters for the properties you care about detecting. If those getters get invoked, the browser knows about those dictionary properties. Ah, perfect - I hadn't thought of that! Thanks! I'll change the spec for that now (https://github.com/RByers/EventListenerOptions/issues/16). Done. How does example 2 look now? http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2 Also, I think that this would make good sense as part of DOM itself, This spec requires changes to DOM anyway, because the spec as written is not valid IDL: It's creating two overloads that can both be called with two arguments. So we'll need to remove the optional annotation from the boolean arg that's already in DOM when we add this new overload. That doesn't seem like a problem. Yeah, plus there's the whole interaction with the 'capture' variable (spec should probably talk about a single 'options' variable with members like 'capture' every place it refers to the 'capture' variable).. I knew I'd never be able to spec it properly on it's own, just enough to get the point across clearly.
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On 7/9/15 1:32 PM, Rick Byers wrote: Done. How does example 2 look now? http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2 Looks like it would work. Also looks kind of ugly because of the object-truthiness bit, but I'm not sure there's any way to avoid that while keeping the overload a boolean and dictionary setup. -Boris
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
Speaking of that, having a new function makes it an option to let mayCancel be false by default, compat-wise at least. That's a good question regardless of which approach we take. Filed https://github.com/RByers/EventListenerOptions/issues/17 I definitely think that if we're going to have any chance of moving significant portions of the web to have better performance, we need things to be fast by default, and then opt-in to slower behavior. And the more we can simply point to these APIs are fast, use these, those APIs are slow, don't use those the better. It should be very clear when you're falling off the fast path. / Jonas
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/9/15 1:32 PM, Rick Byers wrote: Done. How does example 2 look now? http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2 Looks like it would work. Also looks kind of ugly because of the object-truthiness bit, but I'm not sure there's any way to avoid that while keeping the overload a boolean and dictionary setup. I'm not a fan of this approach. It'll be very hard to get users to opt in consistently to the faster behavior. Especially given that it requires much more typing. / Jonas
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 11:52 AM, Rick Byers rby...@chromium.org wrote: On Thu, Jul 9, 2015 at 2:21 PM, Jonas Sicking jo...@sicking.cc wrote: ... I agree 100% with this principle. Changed mayCancel to default to false: https://github.com/RByers/EventListenerOptions/commit/b6ca043c9f13cea773a9338d580a0ebc24ea8140 . This raises a related question though - is the 'mayCancel' name strong enough to indicate performance implications to developers? I personally still kind of like the 'blocksScroll' design instead: https://github.com/RByers/EventListenerOptions/issues/14 I don't like making this specific to scrolling, that doesn't explain what it really means in terms of the capabilities of the event handler. We probably want to use this for other event types where we want to change the time the event dispatches based on if you require the ability to cancel or not as well. - E
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 2:59 PM, Elliott Sprehn espr...@chromium.org wrote: On Thu, Jul 9, 2015 at 11:52 AM, Rick Byers rby...@chromium.org wrote: On Thu, Jul 9, 2015 at 2:21 PM, Jonas Sicking jo...@sicking.cc wrote: ... I agree 100% with this principle. Changed mayCancel to default to false: https://github.com/RByers/EventListenerOptions/commit/b6ca043c9f13cea773a9338d580a0ebc24ea8140 . This raises a related question though - is the 'mayCancel' name strong enough to indicate performance implications to developers? I personally still kind of like the 'blocksScroll' design instead: https://github.com/RByers/EventListenerOptions/issues/14 I don't like making this specific to scrolling, that doesn't explain what it really means in terms of the capabilities of the event handler. We probably want to use this for other event types where we want to change the time the event dispatches based on if you require the ability to cancel or not as well. Yeah, that's a good point. Do you have some specific ideas in mind here? I'm probably too narrowly stuck in input-land :-) - E
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Wed, Jul 8, 2015 at 9:12 PM, Rick Byers rby...@chromium.org wrote:
[Cross-posted to www-...@w3.org - please let me know if there's a better
way to account for the DOM spec duality]
In Chromium we've long worked hard at maximizing scroll performance, with
scroll-blocking DOM events (wheel and touchstart in particular) being by
far the biggest source of scroll jank.
I've been talking about this problem off-and-on for several years with
various folks including the Pointer Events Working Group, engineers of
other browser vendors, and engineers working on popular libraries that are
a source of such scroll-blocking event handlers (eg. Google Ads and
Google Analytics).
I've now written a relatively formal (but still sloppy by W3C standards)
concrete spec for extending the DOM event model
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html to
address this problem and would like to solicit feedback. It's probably
most constructive to discuss specific issues on GitHub
https://github.com/RByers/EventListenerOptions/issues, but I'd appreciate
any high-level feedback here by e-mail too. Please feel free to submit
pull requests for eg. editorial improvements.
Once there's a bit more consensus on the API shape, I plan to write a
polyfill and tests and then begin a prototype implementation in Chromium.
We have some initial evidence to believe that this (in partnership with a
few key library authors) can make a substantial improvement to the user
experience on mobile. I hope to be able to share more concrete data on the
real-world performance impact, but there's obviously a chicken and egg
problem here.
I think this looks like a very promising approach. Would there be any
way to feature detect support for EventListenerOptions as the third
argument? It seems like a problem that addEventListener(type,
callback, { mayCancel: false }) would be treated as
addEventListener(type, callback, true) in existing browsers.
Also, I think that this would make good sense as part of DOM itself,
in particular to get rid of the calls to preventDefault will be
ignored patching of DOM algorithms. https://github.com/whatwg/dom is
open for pull requests, or at least I've done some trivial ones.
Anne, what do you think?
Philip
[whatwg] FW: DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
Date: Thu, 9 Jul 2015 14:42:07 +0200
From: phil...@opera.com
I think this looks like a very promising approach. Would there be any
way to feature detect support for EventListenerOptions as the third
argument? It seems like a problem that addEventListener(type,
callback, { mayCancel: false }) would be treated as
addEventListener(type, callback, true) in existing browsers.
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#extensions-to-the-event-interface
and
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#examples
example 2 are intended to cover this.
--
James Ross ja...@james-ross.co.uk
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 9:05 AM, James Ross w3c-20040...@james-ross.co.uk
wrote:
Date: Thu, 9 Jul 2015 14:42:07 +0200
From: phil...@opera.com
I think this looks like a very promising approach. Would there be any
way to feature detect support for EventListenerOptions as the third
argument? It seems like a problem that addEventListener(type,
callback, { mayCancel: false }) would be treated as
addEventListener(type, callback, true) in existing browsers.
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#extensions-to-the-event-interface
and
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#examples
example
2 are intended to cover this.
Right, thanks. What I've suggested is kind of weird though. Olli raises a
good point https://github.com/RByers/EventListenerOptions/issues/16 that
we should discuss general dictionary-member feature detection patterns in
the abstract before committing to something like this. I'd love other
opinions / ideas on the bug
https://github.com/RByers/EventListenerOptions/issues/16.
--
James Ross ja...@james-ross.co.uk
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 9:39 AM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 9:05 AM, James Ross w3c-20040...@james-ross.co.uk
wrote:
Date: Thu, 9 Jul 2015 14:42:07 +0200
From: phil...@opera.com
I think this looks like a very promising approach. Would there be any
way to feature detect support for EventListenerOptions as the third
argument? It seems like a problem that addEventListener(type,
callback, { mayCancel: false }) would be treated as
addEventListener(type, callback, true) in existing browsers.
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#extensions-to-the-event-interface
and
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#examples
example
2 are intended to cover this.
Right, thanks. What I've suggested is kind of weird though. Olli raises
a good point https://github.com/RByers/EventListenerOptions/issues/16
that we should discuss general dictionary-member feature detection patterns
in the abstract before committing to something like this. I'd love other
opinions / ideas on the bug
https://github.com/RByers/EventListenerOptions/issues/16.
I should perhaps add that I'd hope developers don't really need to use the
pattern in example #2 explicitly. Instead I expect they'd mostly rely on a
simple polyfill (which I'll take an initial crack at writing once the API
shape settles down a bit).
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 6:03 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 9, 2015 at 12:06 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 2:57 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu
wrote:
On 7/9/15 1:32 PM, Rick Byers wrote:
Done. How does example 2 look now?
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2
Looks like it would work. Also looks kind of ugly because of the
object-truthiness bit, but I'm not sure there's any way to avoid that
while
keeping the overload a boolean and dictionary setup.
I'm not a fan of this approach. It'll be very hard to get users to opt
in consistently to the faster behavior. Especially given that it
requires much more typing.
Bigger picture, we're seriously exploring in chromium taking both a
carrot
and stick approach to the event-handler jank problem. Carrots are this
new
API, better devtools tooling highlighting the problem, etc. Sticks are
more
controversial so we're not ready to propose anything concrete yet. But
imagine if particularly slow sites that haven't opted out of blocking
handlers got some sort of unresponsive UI notification
(http://crbug.com/504904). The window-greying-out behavior introduced
in
Windows Vista had a very strong impact on developers motivation to
invest in
UI-thread responsiveness :-). Also Google search results already take
page
load time into account
(
http://googlewebmastercentral.blogspot.ca/2010/04/using-site-speed-in-web-search-ranking.html
),
if we could reliably collect scroll jank performance I don't see why that
also wouldn't be a good signal to use in search rankings (though this is
only my personal opinion - no inside knowledge here at all).
Anyway, suffice it to say that I fully agree we can't expect big wins in
practice just by shipping this new API (no matter how simple we make it,
though the simpler the better of course). But I'm still confident that
having an API like this will open a lot of doors that together will lead
to
substantial user-experience improvements on the web.
Yes, I think that's the right way to think about it.
I think we need new APIs which enable people to do the scroll effects
that they want without getting jank.
I would imagine that most of the time that people listen for
scrollwheel events it is to actually implement some scrolling effects,
or to override the scrollwheel to do something other than scroll the
page.
In neither of these situations a { mayCancel: false } feature doesn't
really help. If they are implementing scroll effect using a
non-cancelling event, it will look crappy since the effect won't keep
up to date with the scrolling thread. If they are using the
scrollwheel event to do something other than scrolling, then they
*have* to cancel the event.
So new APIs are clearly needed here, especially for doing
scroll-driven effects. That would be the carrot. And then we need
incentives for people to move off of the old crappy APIs.
(Actually, for the latter use case the current API might actually be
fine since no scrolling will happen, and so janky scrolling isn't a
problem as long as the event handler always cancel.)
Not sure about wheel handlers, but we've got some decent (but still
anecdotal) evidence that a lot of touch handlers AREN'T actually be used to
drive some effect. For example, it seems common to passively monitor touch
events just for the purposes of tracking user activity for analytics and
ads monetization. Similarly touch handlers are often used for fastclick
libraries that never call preventDefault on touchstart or touchmove (only
touchend - if that). In addition it's not uncommon to listen to touch
events in order to drive a horizontal effect (which does preventDefault)
but doesn't call preventDefault for vertical drags - so in combination with
'touch-action: pan-y' we can again rely on mayCancel=false while preserving
all the effects without any additional APIs.
So I do think mayCancel=false by itself is enough to enable higher
performance for a lot of common scenarios (at least for touch - where my
personal focus has all been).
That said, I also agree with your higher level point that we need new APIs
to enable custom scroll behavior that performs well. We're investing in
longer-term projects as part of the Houdini effort for this (scroll
customization, UI worker) and are making some good progress implementing
snap points and position:sticky internally on top of our prototypes. But
those are still full of uncertainty, far from ready for standardization and
really not directly related to any of this DOM events stuff, so perhaps a
topic for another list :-).
The way I see it, mayCancel=false is one small but high tractable and
valuable
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
On Thu, Jul 9, 2015 at 12:06 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 2:57 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/9/15 1:32 PM, Rick Byers wrote:
Done. How does example 2 look now?
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2
Looks like it would work. Also looks kind of ugly because of the
object-truthiness bit, but I'm not sure there's any way to avoid that
while
keeping the overload a boolean and dictionary setup.
I'm not a fan of this approach. It'll be very hard to get users to opt
in consistently to the faster behavior. Especially given that it
requires much more typing.
Bigger picture, we're seriously exploring in chromium taking both a carrot
and stick approach to the event-handler jank problem. Carrots are this new
API, better devtools tooling highlighting the problem, etc. Sticks are more
controversial so we're not ready to propose anything concrete yet. But
imagine if particularly slow sites that haven't opted out of blocking
handlers got some sort of unresponsive UI notification
(http://crbug.com/504904). The window-greying-out behavior introduced in
Windows Vista had a very strong impact on developers motivation to invest in
UI-thread responsiveness :-). Also Google search results already take page
load time into account
(http://googlewebmastercentral.blogspot.ca/2010/04/using-site-speed-in-web-search-ranking.html),
if we could reliably collect scroll jank performance I don't see why that
also wouldn't be a good signal to use in search rankings (though this is
only my personal opinion - no inside knowledge here at all).
Anyway, suffice it to say that I fully agree we can't expect big wins in
practice just by shipping this new API (no matter how simple we make it,
though the simpler the better of course). But I'm still confident that
having an API like this will open a lot of doors that together will lead to
substantial user-experience improvements on the web.
Yes, I think that's the right way to think about it.
I think we need new APIs which enable people to do the scroll effects
that they want without getting jank.
I would imagine that most of the time that people listen for
scrollwheel events it is to actually implement some scrolling effects,
or to override the scrollwheel to do something other than scroll the
page.
In neither of these situations a { mayCancel: false } feature doesn't
really help. If they are implementing scroll effect using a
non-cancelling event, it will look crappy since the effect won't keep
up to date with the scrolling thread. If they are using the
scrollwheel event to do something other than scrolling, then they
*have* to cancel the event.
So new APIs are clearly needed here, especially for doing
scroll-driven effects. That would be the carrot. And then we need
incentives for people to move off of the old crappy APIs.
(Actually, for the latter use case the current API might actually be
fine since no scrolling will happen, and so janky scrolling isn't a
problem as long as the event handler always cancel.)
/ Jonas
