- 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>
[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 -Jacob
Received on Thursday, 28 August 2014 20:58:14 UTC