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

On Wed, Oct 8, 2014 at 3:33 PM, Benjamin Poulain <benjamin@webkit.org>
wrote:

> This is an interesting idea to explore. I would be curious to see the
> demos.
>

Thanks Benjamin!  I was just about to e-mail you to ask for your input :-)

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

Yes sorry, this document was originally chromium specific (in chromium we
suppress sending touchmoves until the finger has moved far enough to start
a scroll - details here
<https://docs.google.com/a/chromium.org/document/d/12k_LL_Ot9GjF8zGWP9eI_3IMbSizD72susba0frg44Y/edit#heading=h.nxfgrfmqhzn7>).
I've fixed the definition to apply to the behavior of all browsers.

-"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.
>

Agreed, removed.

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

Yeah, this is tough but totally worth exploring.  We want developers to be
able to reason about the correctness of their UI, so we intentionally
avoided giving the browser permission to give up waiting for a scroll event
handler and display the scroll anyway.  We've experimented for awhile with
a system we call "best effort sync scroll" where whenever there are scroll
event handlers we wait as long as possible for them to run without dropping
out of 60fps mode.  What we found is that occasional hiccups cause effects
that are much worse than jank (like jittering up and down).

So our strategy in chromium is to smoothly degrade frame rate.  Eg. if we
can't reliably hit 60fps, then we fall back to a smooth 30fps (as that
looks much better than jumping back and forth between 60 and 30).  We don't
do much fallback beyond this, but it might be worth doing so.

But I think what you're suggesting is disabling scroll events entirely (or
at least during the gesture) when we detect the page isn't performing well
enough.  I'm not sure how to do this without making it difficult for
developers to reason about their behavior (and so again making the
development experience second class relative to native mobile platforms).
I was thinking the problem was best addressed with education - warning
developers not to use this unless they've done performance testing on
low-end hardware.  For your specific case of developing for desktop without
testing on mobile, I'm half tempted to say this feature isn't even
available unless your page indicates it's designed for mobile (eg. via a
meta viewport tag - ugh).  But ultimately this is no worse than an app that
supports dragging with touch events but has never been tested on low end
devices (I've certainly seen a bunch of these - usually due to the use of
some framework that unifies mouse and touch handling).  In the limit we
can't protect developers from themselves, and shouldn't punish
sophisticated developers by treating them the same as naive developers.
But maybe there's something we can do to help encourage the right default
behavior without making things unpredictable.

Do you have any specific suggestions?  Are there examples from other UI
frameworks we can learn from here?

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