Re: scroll-delay WAS: Browsers, Developers and Pointer Events Meeting Notes

On Thu, Aug 28, 2014 at 4:57 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>
wrote:

> [Renaming thread to discuss scroll-delay specifically]
>
> On Thu, Aug 28, 2014 at 10:50 AM, Rick Byers <rbyers@chromium.org> wrote:
> >
> > On Thu, Aug 28, 2014 at 1:32 PM, Arthur Stolyar <nekr.fabula@gmail.com>
> wrote:
> >>
> >> One more thing.
> >>
> >> I understand that separation scroll and touch-move is one of base goals
> of pointer events. But can we have options to disable threaded scroll and
> give control over scroll to developers? I mean full control. Ability to
> stop/resume scrolling in any time while pointer is active and so on.
> >> May be CSS property which disables threaded scroll and then control
> that scroll via JS inside pointermove events.
> >
> >
> > I've got a rough proposal for exactly that sort of thing (I called it
> "scroll-delay") here:
> https://docs.google.com/a/chromium.org/document/d/1aOQRw76C0enLBd0mCG_-IM6bso7DxXwvqTiRWgNdTn8/edit.
>  I personally don't see any reason why carefully engineered apps shouldn't
> be allowed to opt-in to 'scroll-delay: pointermove' causing scrolling to be
> synchronous with event handling.  I'd love any feedback folks have on the
> proposal.
>
> I provided some feedback in Google's doc.


Thanks for the feedback!  I'll reply in the doc soon.  Note that as for
most things we do on the chromium team, this doc is not some "Google"
consensus, but some early brainstorming from one engineer (me).


>   Carefully engineered & simple apps may be able to do this and get good
> enough perf, but the problem is that the API doesn't require you to be a
> carefully engineered app. :-)  Even in a carefully engineered app, the move
> to a more async web platform (e.g. promises, etc) means you can't reliably
> build an app whose main thread will always be untaxed when it's time to
> render a scroll frame. #footguns
>

Do you believe that web developers are inherently less trustworthy in this
regard than Android and iOS developers, or that the web is somehow
inherently more asynchronous than other platforms?  I'm concerned that our
lack of trust for developers is driving the really motivated ones to other
platforms.  We can't protect the world from crappy apps, but we can try to
build a platform where there is strong competition around app quality and
opportunity for great apps to prosper.  The Extensible Web Manifesto
<http://extensiblewebmanifesto.org/> is all about empowering developers
(primarily frameworks) to have more control.  I agree there's risk here, I
just think it's less risky than the alternative of continuing to hold power
back from developers.

Additionally, the requirement to support all these various different
> combinations of synchronous, asynchronous, and dynamically switching
> sync/async scrolling behaviors will insert a significant amount of bloat
> into engines, which seems counter to Blink's goal (and probably ours too).
> We experienced this first-hand when we had to add in sync touchstart/move
> for Touch Events. Your proposal has up to 8 values with several combined
> values also possible.  By my count that's at least 15 different
> configurations (considering some are mutually exclusive).  :-O
>

I absolutely agree this proposal is probably overly complex.  I wanted to
start by explaining all the models I'd seen implemented in practice.  In
reality I suspect we should pick a small subset of possible configurations
that we feel are worth the complexity.

For what it's worth,I believe most of these are pretty easy to implement in
chromium without adding much complexity/bloat if you worry just about the
combined lowest-common-denominator setting for each document (we already
have to make a decision about whether to block scrolling on each of these,
and for the most part have fast-path optimizations in place for the cases
where we know there will be no need to block).  It's tracking the state on
a region-by-region basis that would be complex for us. One possible
simplification then would be to define this as a document-wide property
(maybe it's not CSS, but JS), but then I worry about composition scenarios.


> -Jacob
>