Intent to Implement: scroll-delay

[Rick Byers]

We've decided to separate the most essential (and controversial) piece of the 'beforescroll' proposal (see below) out into an explicit API: scroll-delay.

Primary eng/PM emails rby...@chromium.org, tdre...@chromium.org SpecUnofficial: https://docs.google.com/a/chromium.org/document/d/1aOQRw76C0enLBd0mCG_-IM6bso7DxXwvqTiRWgNdTn8/edit#heading=h.wi06xpj70hhd

Summary Give advanced web applications the ability to force scrolling to run synchronously with JavaScript.

Motivation

Enables arbitrary scroll linked effects that are popular in native mobile UIs to be implemented on the web (using a similar straight forward programming model). Also enables some simple scroll customization effects, and forms the basis for other features (like beforescroll) which enable advanced scroll customization. Compatibility Risk

Firefox: No public signals (and mixed public signals for related beforescroll)

Internet Explorer: Opposed Safari: No public signals Web developers: No signals

We're discussing standardization with the CSS working group.

Describe the degree of compatibility risk you believe this change poses Risk is moderately high. Many people have made the argument that this API is too dangerous to provide to web developers - that most won't do the performance work necessary to ensure a good experience but will use this API anyway, and we'll have a jankier web as a result. Overall the blink team feels we must enable advanced mobile web applications to have this power and continue to invest heavily in fixing any sources of jank in the engine to ensure a 60fps experience is possible (and eventually even easy to achieve).

Note that the web has already shifted once from synchronous to asynchronous scroll events (eg. for Chrome, when we introduced the threaded compositor). If we someday decide scroll-delay was a bad idea (that the threaded fast paths are actually the only way to achieve a 60fps web) we may still be able to make a similarly breaking change again (and at least we'll be able to easily tell which sites claim to be relying on synchronized scrolling).

Ongoing technical constraints Requires us to be able to synchronize scrolling with JavaScript. For now this means forcing scrolling to use the existing blink scrolling code rather than the compositor fast path. In the future (if we ever succeed in unifying our two scroll implementations) it could mean the compositor would need to block producing a frame during a scroll on blink.

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 http://crbug.com/421513 Entry in Chromium Dashboard https://www.chromestatus.com/features/5668176855564288 Requesting approval to ship? No

On Wed, Sep 24, 2014 at 10:51 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

[Darin Fisher]

I'm very supportive of providing this capability to web developers. We should make sure to document the risks and evangelize proper usage.

(It was actually when we made onscroll asynchronous that we first broke web sites that want to manipulate the DOM in response to a scrolled web page.)

-Darin

[Rick Byers]

On Wed, Oct 8, 2014 at 5:22 PM, Darin Fisher <da...@chromium.org> wrote:

I'm very supportive of providing this capability to web developers. We should make sure to document the risks and evangelize proper usage.

Thank you! 

(It was actually when we made onscroll asynchronous that we first broke web sites that want to manipulate the DOM in response to a scrolled web page.)

Ah, makes sense - thanks for the correction. 

[jro...@microsoft.com]

For folks that don't regularly follow W3C mailing list, I just wanted to link here to some of our concerns with this approach to solving this problem.  In short, it feels like we're forcing devs to choose between more reliable performance and bespoke UI experiences.   Something like the UIWorker concept you guys have been exploring likely gets us closer to helping enable more consistent performance across browser runtimes, unlock more expressive/custom UI experiences, and also help rationalize how modern browsers actuall do scrolling today (which, is generally a multi-threaded endeavor).

http://lists.w3.org/Archives/Public/www-style/2014Oct/0201.html 

We'd like to see something like that pursued rather than scroll-delay.

-Jacob

[Jacob Rossi]

I should add that this proposal confused us a bit on Google’s position on scrolling and events.  :-)

 

“scroll-delay: start-touch” makes Touch Events and scrolling mutually exclusive, which is one of the issues you guys cited for not implementing Pointer Events (see reason #3 in http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0051.html). Explaining this rationale further on public-pointer-events/public-touch-events would be great. Thanks!

 

-Jacob

[Rick Byers]

On Fri, Oct 10, 2014 at 4:35 PM, Jacob Rossi <Jacob...@microsoft.com> wrote:

I should add that this proposal confused us a bit on Google’s position on scrolling and events.  :-)

 

“scroll-delay: start-touch” makes Touch Events and scrolling mutually exclusive, which is one of the issues you guys cited for not implementing Pointer Events (see reason #3 in http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0051.html). Explaining this rationale further on public-pointer-events/public-touch-events would be great. Thanks!

Sorry, I think there must be some confusion on the intended design of scroll-delay.  'scroll-delay: start-touch wheel' is the default because it describes exactly the behavior that all browsers have today.  start-touch means that scrolling can't start until JS has been given a chance to consume the touchstart and some number of touchmove events.

Do you mean _excluding_ start-touch from the scroll-delay?  That causes touch events to be uncancelable (i.e. potentially sent asynchronously), so still not mutually exclusive with scrolling (just like how chrome sends throttled async touchmoves during scrolling today).  But it's true that it reduces the expressiveness of touch events (eg. then your only control over what scrolling to permit is touch-action - so you can't, for example, decide to scroll up but not down).  The key here (relative to the trade-offs with pointer events) is that control is in the hands of the developer - they can opt into more control, or opt out and enable more browser fast paths (perhaps event toggling between modes during a single gesture).

I personally still like the fact that pointer events can permit scrolling to start without blocking on JS (it's one of the big reasons we were interested in pointer events in the first place).  I just don't like that it's the only choice (and the defined pointercancel behavior means event handling and scrolling are strictly mutually exclusive - at the far end of the control/perf tradeoff spectrum).  I see a knob like scroll-delay as consistent with the extensible web manifesto - it explains the particular perf/control policy we've chosen and lets the framework override the policy when it's wrong for them (enabling behavior more like IE at one end, or more like Android at the other).