addEventListener('touch-*-async', ...)

[Nat Duca]

Suppose we had "async flavors" of the classic touch events that are never preventDefaultable?

addEventListener('touch-*-async', ...)

And same for mouse, and especially wheel events.

There are a lot of snippets out there for presence monitoring, user interaction heatmapping, that add global handlers on touch and wheel. They only want passive indication that these things have happened. But because of the cancellable semantics of touch and mouse/wheel events, these handlers require us to go to the main thread.

We have things like touch-action: none. But, IMO, this is action at a distance: people add an event listener: asking them to think at the adding-site what semantics they want seems very intuitive, as compared to saying "oh, please go define your semantics over in css."

This seems nice in that its easily-plausibly compatible with other vendors' implementations...

(Fun fact: theverge has a wheel listener. So it can't scroll async on desktop. But we could probably very easily ask them to switch to an async wheel listener. Then theverge would fast scroll!)

~shrug~ insane? Thanks for reading this far!

- N

[Chris Harrelson]

Async events sounds really nice.

I think we need to move in general to a model where any computation which might take lots of time or is not high priority is async and schedulable.

This will unblock a lot of de-jank innovations within the browser, such as throttling, delaying during scroll gestures, etc.

Chris

[Timothy Dresser]

Would we consider adding a "scroll-sync" event, in the same vein as the "*-async" events? Synchronous scroll response is another problem which "scroll-blocks-on" addressed.

[Chris Harrelson]

I think the proposed scroll and distributeScroll methods would handle that case, right? Those are direct extensions of scroll functionality, and so need to be executed synchronously as part of scroll.

[Timothy Dresser]

We were previously thinking that the scroll customization methods would only be called when "scroll-blocks-on: scroll-event" was set. It's a little more explicit that way, instead of transparently opting into main thread scrolling when overriding applyScroll or distributeScroll.

If all you're trying to do is synchronously respond to scrolling, you shouldn't really need to deal with the complexity of overriding the applyScroll method. It's a bit annoying to have to write:

var defaultScrollBehavior = el.applyScroll;

el.applyScroll = function(scrollState) {

  defaultScrollBehavior.call(el, scrollState);

  // Scroll response logic here.

}

That will get a bit cleaner with ES6 classes, but it's still more complicated than would be ideal. 

I suppose there is some benefit to keeping opting in to synchronous scrolling non-trivial though.

[Rick Byers]

I certainly think this is an idea worth exploring.  We want to make performance footguns more obvious to developers, this may be a good way to help in this case.  Note that the choice here is between scroll-blocks-on and an async event API.  touch-action is orthogonal (even with an async event API, you may need to use touch-action to declaratively disable certain gestures since you can no longer use preventDefault for that).

However, one of the use cases scroll-blocks-on was designed to address is where the incentives between components are misaligned and you want some form of "action at a distance".  Eg. we know various libraries (ad networks, etc.) attach touch event handlers, when they'd work perfectly fine with async events.  They may not be properly incentivized to update their code to switch to async handlers, but the page owner wants scrolling to be fast so we should give them the ability to disable scroll-blocking capability of components they're hosting.  Perhaps this is a false use-case though - we can only ever truly fix this sorts of problems through aligning the incentives by fixing our tooling to enable blame attribution.

The other trade off is ease of incremental adoption.  I think our guidance would be one of the following:

1) Find all code in your page (including frameworks etc.) that adds 'touch*' event handlers and evaluate whether each can be conditionally replaced with a 'touch*-async' handler when feature detection indicates your browser supports it.  Also update all code that consults Event.type to be aware of the -async variants.

 

-or-

2) Put 'scroll-blocks-on: none' on your document.  Test the various uses of touch events and if you find one where scrolling is occurring where you don't want it, apply 'touch-action' to that element to disable the unwanted scrolling (or, less desirably, apply 'scroll-blocks-on: start-touch' to re-enable scroll blocking for that element and it's descendants).

I think #2 is easier to apply incrementally to a large application (and so likely to have a bigger positive impact on real world performance) than #1, but I could be wrong.

Also, just from an optics perspective, if we tell people they need to listen to a new type of event, I'm sure we'll get the typical "Why is Google introducing a 3rd type of input events rather than just embracing pointer events which already solved this problem".  Perhaps an API shape like addAsyncEventHandler('touchstart',...) would be better anyway and avoid this concern.

Regarding wheel events.  Why does theverge have a wheel listener at all instead of just a scroll event listener?  What useful capability does a wheel event offer that a scroll event doesn't if you're not going to call preventDefault to disable scrolling?  If there's nothing, then we should be able to argue just as well that people should switch from consuming wheel events to consuming scroll events, rather than introduce an async wheel event.

Rick