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

On Fri, Oct 10, 2014 at 3:09 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>
wrote:
>
> From Rick:
> > In the limit we
> > can't protect developers from themselves, and shouldn't punish
> > sophisticated developers by treating them the same as naive developers.
>
> We're trying to protect users, not developers from themselves.  Despite
> the valid arguments that sites written for desktop without concern for
> mobile are just "bad code", users still expect it to just work. It seems
> reasonable that a user's web browsing experience as a whole is compared to
> native apps. So continuing to add pits of failure for the "naïve
> developers" just makes user perceptions of web vs native grow worse IMO.
>
> Let's avoid labelling these "sophisticated" versus "naïve"
> developers--it's complex desktop web apps versus mobile-optimized. As Ben
> mentions, native apps don't run into some of the unique challenges the web
> runtime imposes. So it's unfair to associate these problems with the
> asserted skill level of the developer.
>

Agreed, sorry for the poor framing.


> With this API, I understand it that we have two configurations essentially:
>
> A) Enable blocking events to build more bespoke experiences
> B) Disabling blocking events to help remove the variability of the runtime
> and help ensure 60FPS and low-latency scroll initiation
>

For what it's worth, B is a non-goal for chromium right now - it's really
only A that we're focused on.  If there's consensus around this, then I'm
OK simplifying scroll-delay to only enable A without enabling B (i.e.
'auto' and 'scroll-event' are the only choices).  But since I knew opinions
differed on this, I thought it was better to avoid polluting web platform
API design with our particular opinion and instead embrace the extensible
web ideal of enabling frameworks to specify the opinion.  Thoughts?

Pointer Events already solved B [1].  Yet, one of the reasons Pointer
> Events has been rejected by Google is that B may remove the capability to
> build certain richer UI experiences [2, 3] (a point that's a bit contested
> as these UI experiences typically have perf problems on the web when built
> with blocking events [3]).  It seems odd to me that your proposing an API
> that brings this mutual exclusivity problem to wheel and touch events. That
> seems to say that we're making developers choose between ensured
> performance and UI customizability--that seems fundamentally wrong.
>

The problem we had with pointer events here is that it makes this policy
decision unilaterally (making such effects impossible).  If the choice is
in the hands of the developer then it's not an issue.  Of course I agree it
sucks to force the developer to choose at all - I'd love to see a concrete
proposal that was strictly upside without any disadvantage.  But the
problem is over constrained - something has got to give.  For the scenarios
we're concerned with here, the main thread already has to be responsive for
the app to be successful, so we don't consider this downside to be that big
of a deal.

> Do you have any specific suggestions?  Are there examples from other UI
> > frameworks we can learn from here?
>
> I agree we need to follow the extensible web manifesto here and built more
> expressive primitives for scrolling.  Those primitives should explain the
> underlying browser platform.  Given all major browsers now have
> multi-threaded scrolling architectures, it follows that the primitives
> should take advantage of that. The current proposal actually backs away
> from explaining the underlying platform and instead tries to shim the
> platform into sort-of/kind-of/but-not-really working like iOS/Android app
> scrolling. While yes we can improve main-thread-synchronous performance, it
> will never eclipse what can be achieved with multi-threaded scrolling.  My
> 2 year old phone has 4 cores--the web should be empowered to take advantage
> of that and maybe even use that to eclipse native performance.
> Non-blocking, multi-threaded scrolling is what enables the web platform to
> escape the additional challenges Ben mentioned about runtime variances.
>
> For these reasons, it seems much more rational to continue investigating
> isolated script contexts that can control scrolling and manipulation while
> more accurately explaining how the underlying platform actually works.
> You've mentioned a UIWorker concept that sounds intriguing along these
> lines.  It avoids the pits of failure for perf, allows bespoke UI
> experiences, and helps developers overcome the challenges of building for
> runtimes and devices of varying performance characteristics. I think
> something like that is a better approach than scroll-delay.
>

Both approaches have their risks and trade-offs.  For the scenarios we're
most concerned with (mobile-optimize apps already relying on handling 60fps
input every frame), confining your UI logic to a single thread (the way you
do on all other platforms) seems like the simpler choice.  I don't see any
reason why the platform shouldn't support both approaches though - enabling
both styles of high-performance UI development and letting developers
choose is probably the only way we're really going to resolve this debate
anyway ;-)

Rick