Intent to Implement: beforescroll event

[Timothy Dresser]

Primary eng/PM emails

tdre...@chromium.org, rby...@chromium.org, inpu...@chromium.org

Spec
Rough Proposal

Discussing formal standardization with CSSWG: bug

Summary
Implement synchronous 'beforescroll' event, allowing for jitter free scroll response effects and scroll customization. This event will also help explain our current scrolling behavior.

Motivation
Many native mobile applications have UI effects synchronized with scrolling.  Implementing these effects on the web currently involves re-implementing all of scrolling on top of raw input. The beforescroll event allows the implementation of a variety of UI effects without re-implementing scrolling, at the cost of disabling the threaded scrolling fast-path.

 
Compatibility Risk
Firefox: Mixed public signals (negative, positive)
Internet Explorer: Public skepticism
Safari: Public skepticism
Web developers: No signals

The full discussion is here:

http://lists.w3.org/Archives/Public/www-dom/2014JulSep/0134.html
http://lists.w3.org/Archives/Public/www-style/2014Sep/0252.html
http://lists.w3.org/Archives/Public/www-style/2014Sep/0297.html

Web Input Face to Face notes

Other browser vendors are hesitant to add new APIs which enable opting in to main thread scrolling. We believe this is necessary in order to compete with the flexibility offered by native app platforms. We plan to work hard to try to find a solution acceptable to all the vendors before shipping anything.

Ongoing technical constraints
We may constrain scrolling such that it must be implementable using the beforescroll event and the normal event dispatch flow.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux,
Chrome OS, and Android)? Yes or no.
Yes.

OWP launch tracking bug
https://code.google.com/p/chromium/issues/detail?id=416862

Entry in Chromium Dashboard
http://www.chromestatus.com/features/5616710262456320

Requesting approval to ship?
No

[PhistucK]

At least on desktop -

window.addEventListener("wheel", function (e) { e.preventDefault()}, false);

Behaves similarly, I guess.

On mobile -

window.addEventListener("touchstart", function (e) { e.preventDefault()}, false);

And with keyboard, looking for the right keyCode on keydown would yield the same, so it is already pretty possible. You basically want to unify the various ways, right?

☆PhistucK

[Timothy Dresser]

This proposal isn't focused on unifying the ways you can currently interact with scrolling.

Neither of the approaches you mention are composable with native scrolling - if you implement a component with one of those approaches and then nest it inside a native scroller, or nest a native scroller inside it, you'll run into issues.

The beforescroll event allows you to customize the distribution of scroll deltas, which neither of those events allow.

For example, you could implement a div with fully custom scrolling (perhaps with fancy 3D effects!) which participated in scroll chaining, by listening to the beforescroll event and calling consumeDelta appropriately.

This will allow web components to replace native scrollers seamlessly, enabling lots of previously impossible effects.

Tim Dresser

[PhistucK]

This also calls for a lot of possible jank without using a big hammer such as iScroll and similar. I think the graphics/input/performance teams were trying to move away from synchronous events such as this one (especially with regards to scrolling), not implement a new one...

☆PhistucK

[Timothy Dresser]

We(input-dev),  have found that it’s possible to build 60fps mobile web apps that rely on running JS every frame, and we intend this feature to be used only by applications that have done the necessary performance work (which is often necessary anyway for other UI effects such as dragging).

In order to compete with native mobile apps in flexibility and ease of development, we need a way to customize scrolling behavior on a per-frame basis.

[Rick Byers]

Note that Nat Duca recently gave a great talk on this change in our philosophy over the past year: https://www.youtube.com/watch?v=3Bq521dIjCM.

The downside here of course is that it means many existing (not optimized for mobile) web pages won't simply be able to take advantage of the beforescroll event without killing their scrolling performance.  That's the same problem as trying to add some rich touch-dragging effect to your site - today that's only possible to do without jank if your entire app is designed for a responsive main thread.

Rick

[Adam Barth]

On Wed Sep 24 2014 at 7:35:20 AM 'Timothy Dresser' via blink-dev <blin...@chromium.org> wrote:

We(input-dev),  have found that it’s possible to build 60fps mobile web apps that rely on running JS every frame, and we intend this feature to be used only by applications that have done the necessary performance work (which is often necessary anyway for other UI effects such as dragging).

In order to compete with native mobile apps in flexibility and ease of development, we need a way to customize scrolling behavior on a per-frame basis.

Yeah, today authors are faced with poor alternatives.  Either then re-implement scrolling themselves or they're stuck with hard-to-customize threaded scrolling.

What I like about this proposal is that it seeks a happy middle ground whereby authors can use the browser's built-in scrolling machinery but still have the power to fully customize the visual effect.

On Tue, Sep 23, 2014 at 6:02 PM, PhistucK <phis...@gmail.com> wrote:

This also calls for a lot of possible jank without using a big hammer such as iScroll and similar.

We've been studying this use cases, and currently the only way we know of to achieve them is for authors to re-implement scrolling (what you call "a big hammer").

I think the graphics/input/performance teams were trying to move away from synchronous events such as this one (especially with regards to scrolling), not implement a new one...

There's a diversity of opinion about how to solve these problems.  Hopefully by implementing beforescroll behind a flag we'll gain implementation experience that will inform discussions about these topics.

Adam