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

On Wed, Oct 8, 2014 at 11:44 AM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> 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?
>

Right, although it's not just about starting a scroll.  Both 'wheel' and
'scroll-event' control blocking of each frame during a scroll.  Today
browsers all block mouse/touchpad scrolling every frame on wheel event
handlers, but they don't block during touch-based scrolling.  By adding
'scroll-event' you get a chance to update style (transforms, other scroll
offsets) based on a scroll of any kind before that scroll becomes visible
to the user.


>
> This sounds interesting and reasonable.
>
> ~TJ
>