Primary eng/PM emails
tdre...@chromium.org, rby...@chromium.org, inpu...@chromium.org
Spec
Houdini CSS-Scroll spec (location of future spec)
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
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
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 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.AdamOn 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 DresserOn 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?☆PhistucKOn 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 ProposalDiscussing 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 signalsThe 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
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
"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."
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
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.