Re: [blink-dev] Re: Intent to Implement: beforescroll event

[Timothy Dresser]

We've heavily modified our proposal since this intent to implement was sent.
Here's an updated intent reflecting our more recent work.

Intent to Implement: Scroll Customization

Primary eng/PM emails

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

Spec

Rough Proposal

Houdini CSS-Scroll spec (location of future spec)

Summary

Add applyScroll and distributeScroll methods to Element, enabling customization of how scroll deltas are applied and distributed. This will enable extending and replacing native scrolling behaviors.

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. Scroll customization enables a variety of UI effects without re-implementing scrolling. The initial implementation will focus on enabling scroll customization at the cost of disabling fast path scrolling, but future work will enable scroll customization of off-main-thread scrolling.

 
Compatibility Risk

Firefox, Internet Explorer, Safari: Mixed Signals

From houdini IRC log: 

| dean: experiment/implement and report back 

| rbyers: prototypes landing soon 

| ... 

| RESOLVED: rbyers TabAtkins mattrakow to work on CSS Scroll Extensions

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 will constrain native scrolling such that it must be implementable entirely in the applyScroll and distributeScroll methods.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)? 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

On Wed Sep 24 2014 at 10:51:05 PM Adam Barth <aba...@chromium.org> wrote:

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

 

On Tue, Sep 23, 2014 at 10:50 PM, Timothy Dresser <tdre...@google.com> wrote:

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

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

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

On Tue, Sep 23, 2014 at 9:14 PM, 'Timothy Dresser' via input-dev <inpu...@chromium.org> wrote:

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

[Rick Byers]

FWIW, I think we've got some positive signals from web developers that this is a problem we need to solve.  Eg. in Flipboard's recent post they said:

"Scrollable elements are possible in pure HTML and CSS with overflow: scroll (combined with-webkit-overflow-scrolling: touch on iOS) but these do not give you frame-by-frame control over the scrolling animation and mobile browsers have a difficult time with long, complex content." 

...

"Recently, iOS and Android have exposed onscroll events that work more like they do on desktop browsers but your mileage may vary if you are trying to keep DOM elements synchronized with the scroll position.  Luckily, browser vendors are aware of the problem. In particular, the Chrome team has been open about its efforts to improve this situation on mobile."

Rick

[Philip Jägenstedt]

I'm no expert on input or scrolling, but this all looks very promising.

Could the mixed signals from other vendors be condensed into something more accessible? I only know roc by nickname.

Other than getting this off the main thread, is there any scroll effect that native apps can do which would not be possible with this proposal?

The document and one of the figures mentions rails, is that snapping a fling to a single axis so that it doesn't drift slightly in the other axis?

There's also the question of "This doc assumes that at most a single scroll is active in a document at once. What if, for example, JS attempts to scroll while an input scroll is in progress?" Do Web apps currently like to nest scrolls like that, and why? If there's no use case that couldn't be done using the new API, it might be worth adding use counters to see if it would be possible to simply ignore attempts to scroll while already scrolling.

Philip

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Timothy Dresser]

On Mon Feb 23 2015 at 9:56:28 AM Philip Jägenstedt <phi...@opera.com> wrote:

I'm no expert on input or scrolling, but this all looks very promising.

Could the mixed signals from other vendors be condensed into something more accessible? I only know roc by nickname.

Dean Jackson (Apple), Robert O'Callahan (Mozilla), Rossen Atanassov (Microsoft), and others resolved to start a CSS Scroll extensions spec.

Next steps include writing an implementation and reporting back. People are concerned about the performance characteristics of the main thread implementation. 

Other than getting this off the main thread, is there any scroll effect that native apps can do which would not be possible with this proposal?

This proposal is similar to the way native app frameworks allow scroll customization. I'm not aware of any scroll effect native apps can do which will not be possible with this proposal. There are some other effects that still won't be possible, for security reasons. For instance, it won't be possible to hide the URL bar immediately on page load, as that's a security concern. 

 

The document and one of the figures mentions rails, is that snapping a fling to a single axis so that it doesn't drift slightly in the other axis?

Rails is snapping a scroll to a single axis, not just a fling. If the user's finger follows an axis closely during a scroll, we assume they meant to scroll precisely along that axis.

 

There's also the question of "This doc assumes that at most a single scroll is active in a document at once. What if, for example, JS attempts to scroll while an input scroll is in progress?" Do Web apps currently like to nest scrolls like that, and why? If there's no use case that couldn't be done using the new API, it might be worth adding use counters to see if it would be possible to simply ignore attempts to scroll while already scrolling.

While investigating how to implement pull-to-refresh style scenarios with existing web technologies, I played with applying "friction" to a scroll by using JS to scroll in the opposite direction of the user's scroll. I expect this approach to applying "friction" to a scroll is reasonably common.

It may be possible for us to solve the problems that arise with multiple simultaneous scrolls. If it's reasonably straight forward, enabling these scenarios is probably the right approach.

Tim

[Philip Jägenstedt]

Thanks for the details, Tim, and good luck with the implementation!