- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 8 Oct 2014 08:44:09 -0700
- To: Rick Byers <rbyers@chromium.org>
- Cc: "www-style@w3.org" <www-style@w3.org>, Nathaniel Duca <nduca@chromium.org>, Timothy Dresser <tdresser@chromium.org>
On Wed, Oct 8, 2014 at 6:56 AM, Rick Byers <rbyers@chromium.org> wrote: > Based on feedback to our scroll customization proposal ("beforescroll"), we > propose separating out the most essential (and contentious) piece: a way for > developers to specify which DOM events scrolling must be synchronized with. > Details are in this document, but briefly we propose a new CSS property: > > ‘scroll-delay’ > Value: none | inherit | [ start-touch || wheel || scroll-event ] > Initial: start-touch wheel > Applies to: all elements > Inherited: yes > > By adding 'scroll-event' to the list of things that can "delay" scrolling, > an app can build arbitrary "scroll response" effects (eg. parallax, "hidey > bars", scroll headers) and we believe basic "scroll customization" effects > (eg. snap points, limited scroll-end bounce). Of course this puts a > performance optimization burden on the developer to ensure they can still > achieve 60fps scrolling, and so is not something the vast majority of > websites should opt into. We believe this is essential for sophisticated > mobile web applications to provide a native-like user experience with a > similar programming model to native mobile platforms. We're working on a > prototype implementation in chromium and demos of various effects now. > > This API can also be used to allow websites to improve scroll responsiveness > by removing some of the default blocking behavior. For example, browsers > that implement touch events and the touch-action CSS property can override > the default to remove 'start-touch' from the list so that scrolling can be > permitted to start without blocking on any touch events. > > Rich scroll customization (eg., for pull to refresh) still requires an API > for mediating composition between scrollers (such as beforescroll), but we > now believe such an API is best built on top of an explicit opt-in mechanism > like scroll-delay. 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? This sounds interesting and reasonable. ~TJ
Received on Wednesday, 8 October 2014 15:44:57 UTC