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

On Wed, Oct 8, 2014 at 6:56 AM, Rick Byers <rbyers@chromium.org> wrote:
> Based on feedback to our scroll customization proposal ("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, 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 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.

Ah, so if a value is specified in the property, the browser will block
on the appropriate event to fire and be handled before starting to
scroll; if it's not, the browser is free to immediately trigger a
scroll, possibly off-thread?

This sounds interesting and reasonable.

~TJ

Received on Wednesday, 8 October 2014 15:44:57 UTC