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

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

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

Received on Friday, 29 August 2014 03:10:35 UTC