- From: Benjamin Poulain <benjamin@webkit.org>
- Date: Wed, 08 Oct 2014 12:33:10 -0700
- To: Rick Byers <rbyers@chromium.org>, "www-style@w3.org" <www-style@w3.org>
- CC: Nathaniel Duca <nduca@chromium.org>, Timothy Dresser <tdresser@chromium.org>
This is an interesting idea to explore. I would be curious to see the demos. Some comments: -"the touchstart and first touchmove event block scrolling" Including the first touchmove seems arbitrary. The first touch move may not carry any useful information. -"scroll-event [...] may be used to eliminate the possibility of checkerboarding". Removing checkboarding is too strong. I don't see how any page could guarantee this on most hardware, too much of this it hardware dependent. -It would be good to evaluate what should happen when a page does not respond in a reasonable amount of time. For example, what if someone use scroll-delay on OS X and the page is loaded on a Firefox phone? It may be useful to have an explicit mitigation algorithm if a page gets below 60 (30?)FPS. If the hardware cannot sustain a certain speed with scroll-event, there should be a way to shortcut the graphical effects. Benjamin On 10/8/14, 6:56 AM, Rick Byers wrote: > Based on feedback to our scroll customization proposal > <http://lists.w3.org/Archives/Public/www-style/2014Sep/0297.html> > ("beforescroll"), we propose separating out the most essential (and > contentious) piece: a way for developers to specify which DOM events > scrolling must be synchronized with. Details are in this document > <https://docs.google.com/a/chromium.org/document/d/1aOQRw76C0enLBd0mCG_-IM6bso7DxXwvqTiRWgNdTn8/edit#>, > but briefly we propose a new CSS property: > > ‘scroll-delay’ > Value:none | inherit | [ start-touch || wheel || scroll-event ] > Initial: start-touch wheel > Applies to: all elements > Inherited: yes > > By adding 'scroll-event' to the list of things that can "delay" > scrolling, an app can build arbitrary "scroll response" effects (eg. > parallax, "hidey bars", scroll headers) and we believe basic "scroll > customization" effects (eg. snap points, limited scroll-end bounce). Of > course this puts a performance optimization burden on the developer to > ensure they can still achieve 60fps scrolling, and so is not something > the vast majority of websites should opt into. We believe this is > essential for sophisticated mobile web applications to provide a > native-like user experience with a similar programming model to native > mobile platforms. We're working on a prototype implementation in > chromium <https://code.google.com/p/chromium/issues/detail?id=347272> > and demos of various effects now. > > This API can also be used to allow websites to improve scroll > responsiveness by removing some of the default blocking behavior. For > example, browsers that implement touch events and the touch-action CSS > property can override the default to remove 'start-touch' from the list > so that scrolling can be permitted to start without blocking on any > touch events. > > Rich scroll customization (eg., for pull to refresh) still requires an > API for mediating composition between scrollers (such as beforescroll), > but we now believe such an API is best built on top of an explicit > opt-in mechanism like scroll-delay. > > Thoughts? Thanks, > Rick >
Received on Wednesday, 8 October 2014 19:36:39 UTC