Re: Touch scrolling after preventDefault called on first touchmove event

I've pushed this to the v1-errata branch.

The diff can be seen here:
https://dvcs.w3.org/hg/webevents/diff/0c110aed1866/touchevents.html

The updated version of the spec can be seen here:
https://dvcs.w3.org/hg/webevents/raw-file/v1-errata/touchevents.html#the-touchmove-event

Let me know if you have any feedback.
Tim


On Thu, Jul 24, 2014 at 11:25 AM, <cathy.chan@nokia.com> wrote:

>  LGTM. Thanks Tim.
>
> - Cathy.
>
>
>
> *From:* ext Timothy Dresser [mailto:tdresser@google.com]
> *Sent:* Thursday, July 24, 2014 10:55 AM
> *To:* Chan Cathy (Nokia-CTO/Boston)
> *Cc:* Rick Byers; Kornel Lesiński; public-touchevents@w3.org
>
> *Subject:* Re: Touch scrolling after preventDefault called on first
> touchmove event
>
>
>
> I think adding a note indicating that behavior after the first uncancelled
> touchmove event is implementation dependent is worthwhile. Does this look
> reasonable?
>
>
> "A user agent should suppress the default action caused by any touchmove
> event until at least one touchmove event associated with the same active
> touch point is not cancelled. Whether the default action is suppressed for
> touchmove events after at least one touchmove event associated with the
> same active touch point is not cancelled is implementation dependent ."
>
>
> On Wed, Jul 23, 2014 at 5:47 PM, <cathy.chan@nokia.com> wrote:
> >
> > > From: tdresser@google.com [mailto:tdresser@google.com] On Behalf Of
> ext Timothy Dresser
> > >
> > >> On Tue, Jul 22, 2014 at 2:24 PM, <cathy.chan@nokia.com> wrote:
> > >>> From: tdresser@google.com [mailto:tdresser@google.com] On Behalf Of
> ext Timothy Dresser
> > >>>> On Fri, Jul 18, 2014 at 5:01 PM, <cathy.chan@nokia.com> wrote:
> > >>>>> From: ext Rick Byers [mailto:rbyers@google.com]
> > >>>>> On Fri, Jul 18, 2014 at 11:27 AM, Timothy Dresser <
> tdresser@chromium.org> wrote:
> > >>>>>> If we used: "If *any* touchmove event is cancelled", then I think
> Firefox would be in violation of the spec, as they only depend on whether
> or not the first touchmove event is cancelled.
> > >>>>>>
> > >>>>>> Would this be preferable?
> > >>>>>>
> > >>>>>> "A touchmove event should cause no default action until a
> touchmove
> > >>>>>> event associated with the same active touch point is not
> cancelled."
> > >>>>>>
> > >>>>> I'd replace "until a touchmove event" with "unitl at least one
> touchmove event" just to be explicit.
> > >>>>>
> > >>>> Isn't that just the standard behavior? An event is either
> explicitly cancelled or not cancelled. Let's say the first touchmove event
> is cancelled, and the fifth touchmove event is the first one that is "not
> cancelled". That would mean that touchmove events #2, 3 and 4 were all
> cancelled. Even without the requirement above, there would be no default
> actions on the first 4 events, because they were explicitly cancelled. Am I
> missing something?
> > >>>
> > >>> The key difference is that behavior once a touchmove event has been
> left uncancelled is undefined.
> > >>>
> > >>>>> Basically what we're trying to say here is that browsers are
> required to suppress scrolling for a touch sequence as long as all the
> moves are being cancelled.
> > >>>>> As soon as a move occurs that isn't cancelled then the browser MAY
> or MAY NOT scroll (since implementations have always differed here).
> > >>>> I think what you mean is that after a touchmove event is cancelled,
> the UA may choose to (or choose not to) continue to implicitly cancel
> subsequent touchmove events that are not cancelled. This continues until
> the next touchmove event(s) is cancelled, at which point the UA must
> s6uppress the default action for that event/those events, and may make
> another decision about the non-cancelled events that follow, and so on.
> > >>>
> > >>> Not quite, once any touchmove event has been left uncancelled,
> > >>> even if another touchmove is cancelled, the user agent can decide
> whether or not to prevent its default action.
> > >> I'm sorry if I'm a little dense. Are you saying that the user agent
> can decide to not prevent the default action even if a touchmove event is
> cancelled? That doesn't feel quite right.
> > >
> > > That's correct. The spec previously allowed for this, and most
> browsers behave this way in some cases.
> > >
> > >>> What you've described here would mean that browsers which only pay
> attention to whether or not the first touchmove event was cancelled would
> become in violation of the spec.
> > >>>>
> > >>>> Would this capture the behavior?
> > >>>> [[
> > >>>> If the preventDefault method is called on any touchmove event of an
> active touch point, it should prevent any default action caused by
> subsequent touchmove events associated with the same active touch point on
> which the preventDefault method is not called, such as scrolling.
> > >>>> ]]
> > >>> If I understand this correctly, its much too strict. Chrome, Safari,
> and Firefox all allow default actions for a touch point which previously
> received a cancelled touchmove event.
> > >>
> > >> How about a couple of examples to help understand what kind of
> behavior(s) we want to allow?
> > >>
> > >> Example 1:
> > >> First N touchmove events are cancelled. (A)
> > >> Next N touchmove events are not cancelled. (B)
> > >> Then another N touchmove events are cancelled. (C)
> > >> Finally another N touchmove events are not cancelled. (D)
> > > See example here: http://jsbin.com/dexax/28?quiet=1 (N = 10)
> > > *     Chrome (Canary):
> > >   o   No scrolling in A.
> > >   o   Scrolling in B.
> > >   o   You can't cancel events during scroll, indicated by the
> event.cancelable flag being set to false, so there is scrolling during C.
> > >   o   Scrolling in D.
> > > *     Safari: No scrolling occurs (when document scrolling).
> > >   o   div scrolling and div scrolling with
> "-webkit-overflow-scrolling: touch;" behave differently.
> > > *     Firefox: No scrolling occurs.
> > >
> > >> Example 2:
> > >> First N touchmove events are not cancelled.
> > >> Next N touchmove events are cancelled.
> > >> Then another N touchmove events are not cancelled.
> > >> Finally another N touchmove events are cancelled.
> > > See example here: http://jsbin.com/wacuc/3?quiet=1 (N=10)
> > > *     Chrome: No cancelable touchmove events are received, so
> scrolling always occurs.
> > > *     Safari: Always scrolls (when document scrolling). Events are
> marked cancelable.
> > > *     Firefox: Always scrolls. Events are marked cancelable.
> > >> What would be the respective behavior in Chrome, Safari and Firefox?
> > >
> > > See
> https://docs.google.com/a/chromium.org/document/d/12k_LL_Ot9GjF8zGWP9eI_3IMbSizD72susba0frg44Y/edit#heading=h.nxfgrfmqhzn7
> for some details on behaviors in different browsers.
> >
> > Many thanks Tim. I think (hope?) I do get it now. I'd suggest a little
> modification on your latest proposal (along with Rick's tweak).
> > "A sequence of touchmove events should cause no default action until at
> least one touchmove event associated with the same active touch point is
> not cancelled."
> >
> > Alternatively,
> > "A user agent should suppress the default action caused by any touchmove
> event until at least one touchmove event associated with the same active
> touch point is not cancelled."
> >
> > I also wonder if it's worth it to add a note that after the first
> uncancelled touchmove event, the behavior is implementation dependent.
> >
> > - Cathy.
>