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

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

> On Thu, Aug 28, 2014 at 2:12 PM, Rick Byers <rbyers@chromium.org> wrote:
> >
> > 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).
>
> Understood. /s/Google's doc/Google Doc [tm]. :-)
>
> >>
> >>   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 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.
>
> It's not an issue of trustworthiness in the least. It's a technical issue
> that the web platform is fundamentally (and beautifully IMO) different from
> Android/iOS/WP patterns. For example, at the web's heart is a rich a
> dynamic mash-up of content.  One single developer or team of developers
> doesn't write all the code nor is that code packaged up together at once.
> Rather, here's a Like button or a commenting system, or a widget, or a this
> or a that that's composed together.  Each using different coding patterns,
> frameworks, and APIs.  Web Components embraces this! All of that is
> dynamic, and at-will one of those components might change (e.g. suddenly a
> widget switches from setTimeout to requestAnimationFrame and the timings
> are all different), fundamentally altering the conditions and timings you
> tested and deployed with. The web also has less capable threading APIs (a
> problem I've discussed with Adam Barth and others before), which means some
> of the tools on Android/iOS/WP can't apply to the web (yet).
>

FWIW I think this is a very good point.  Having a single UI thread is a big
problem for "performance modularity" (being able to better reason about the
performance of your component in isolation).  To me this is a compelling
argument for a UI platform where each component can have separate UI
threads, although this is far from a consensus on the blink team.  I think
we're just debating about the middle ground here - in the absence of a
fully multi-threaded UI, how much "magic" (uncustomizable special cases)
are we willing to have to try to paper over the problem?  The Extensible
Web Manifesto says we shouldn't introduce new magic that can't be explained
in terms of primitives.  Of course we've had threaded scrolling for a few
years now...

>> 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.
>
> Since at least some of these different settings are founded in specific
> different UI experiences,  I think the expectation is that this can be
> applied to any element differently (consider the mash-up nature of the web
> where one component might want one thing and something else another).
>

I was hoping we could formulate it as components expressing their minimum
synchronization requirements and the UA could choose to provide any level
of synchronization at or above that level.  That way functionality is
predictable locally but performance requires global co-ordination (as is so
often the case already today).  Eg. in chromium we'd most easily apply this
on a per-layer basis.