W3C home > Mailing lists > Public > public-pointer-events@w3.org > July to September 2014

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

From: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Thu, 28 Aug 2014 20:57:41 +0000
To: Rick Byers <rbyers@chromium.org>, Arthur Stolyar <nekr.fabula@gmail.com>
CC: "public-pointer-events@w3.org" <public-pointer-events@w3.org>, "public-touchevents@w3.org" <public-touchevents@w3.org>
Message-ID: <0b3d036fc9274b47bbe95bdcc209d1e6@BY2PR03MB457.namprd03.prod.outlook.com>
[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.  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  

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

Received on Thursday, 28 August 2014 20:58:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:10 UTC