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

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

Exposing primitives for authoring threaded effects seems tough to get
right, though, judging by the wide variety of proposed solutions. To reach
consensus and implementation on this feels like a medium to long term task,
but please do correct me if I'm mistaken.

If that's true, do we have another near term approach save scroll-delay
that can help web devs that are currently trying to author custom
scroll-linked effects?

As I understand it, scroll-delay doesn't preclude exploring threaded
solutions, and the main issue is misuse of the property; that the wrong
sorts of pages will use it and hurt their perf characteristics. Does Rick's
scroll-delay-failed suggestion address this?