scroll-delay: enabling control over the scrolling synchronization policy

Based on feedback to our scroll customization proposal
<http://lists.w3.org/Archives/Public/www-style/2014Sep/0297.html>
("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
<https://docs.google.com/a/chromium.org/document/d/1aOQRw76C0enLBd0mCG_-IM6bso7DxXwvqTiRWgNdTn8/edit#>,
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
<https://code.google.com/p/chromium/issues/detail?id=347272> 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.

Thoughts?  Thanks,
   Rick