Re: Touch scrolling after preventDefault called on first touchmove event

Given that the goal of the touch-events v1 spec was to retroactively
describe the common behavior of the major browsers (including mobile
Safari), and mobile Safari has (as far as I know) always done what you
suggest in the case of divs without -webkit-overflow-scrolling: touch, I'm
pretty comfortable calling this a spec bug (although I can understand the
desire to want to define some behavior here).  Matt (editor) probably knows
why they wanted to add this.

To describe the common behavior even of just Safari in all it's different
scenarios I think we'd have to say something pretty vague like "cancelling
the first touchmove event of an active touch point will prevent default
behaviors for that point such as scrolling at least until a touchmove event
is processed that is not cancelled".  Personally I find Safari's behavior
here [1] sufficiently surprising (between documents, divs with and without
-webkit-overflow-scrolling: touch) that trying to capture it in a rational
standard is pretty hard.

Rick

[1]
https://docs.google.com/a/chromium.org/document/d/12k_LL_Ot9GjF8zGWP9eI_3IMbSizD72susba0frg44Y/edit#heading=h.nxfgrfmqhzn7


On Thu, Apr 17, 2014 at 3:20 PM, Timothy Dresser <tdresser@chromium.org>wrote:

> 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
>