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

>From Tab:
> Ah, so if a value is specified in the property, the browser will block
> on the appropriate event to fire and be handled before starting to
> scroll; if it's not, the browser is free to immediately trigger a
> scroll, possibly off-thread?

Yes and no. If no value is specified, then touchstart/touchmove/wheel still block but scroll does not (given the initial value of "start-touch wheel").  It's confusing that the initial value is that some events block and others don't, but I guess that'd be the only way to compatibly introduce such a feature. 

>From Rick:
> 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).

We're learning the hard way that making features exclusive to mobile vs desktop is bad (e.g. trying to bring touch events to desktop, meta viewport not working well for larger screen sizes, etc). So let's not make that mistake again.  

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

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

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.  

Even for pointer events, we want to unlock A for developers. But not at the expense of reliable performance characteristics.

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

-Jacob


[1] https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#declaring-candidate-regions-for-default-touch-behaviors
[2] https://www.youtube.com/watch?v=ngBy0H_q-GY&t=117
[3] http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0051.html
[4] http://blogs.msdn.com/b/ie/archive/2014/09/05/making-the-web-just-work-with-any-input.aspx

Received on Friday, 10 October 2014 19:09:56 UTC