Re: scroll-delay: enabling control over the scrolling synchronization policy

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