Touch scrolling after preventDefault called on first touchmove event

We’re thinking of modifying the way chromium behaves when the
preventDefault method is called on the first touchmove event of an active
touch point. This currently prevents the active touch point from ever
causing scrolling, but we are considering allowing scrolling to begin later
if additional touchmove events are received which have not had their
preventDefault method called. This does not deviate significantly from
existing browser behaviors and increases the expressiveness of touch events
in chromium.

This change violates the spec, which states:

> If the preventDefault method is called on the first touchmove event of an
active touch

> point, it should prevent any default action caused by any touchmove event
associated

> with the same active touch point, such as scrolling.

(http://www.w3.org/TR/touch-events/#the-touchmove-event)

Safari’s behavior when scrolling divs (without -webkit-overflow-scrolling:
touch) already violates this portion of the spec. Even if the first
touchmove event has its preventDefault method called, Safari will scroll if
it receives a later touchmove event which has not had its preventDefault
method called.

The spec provides no way to prevent the beginning of a scroll from
occurring and then allow scrolling later. Deviating from the spec by
allowing scrolling after the first touchmove event has had its
preventDefault method called allows this to occur, with little risk of
browser compatibility issues. We’ve found this additional flexibility
necessary to achieve a variety of effects, such as pull-to-refresh.

Is this deviation from the spec justified?

If you have any questions or feedback, please let me know.

Thanks!
Tim