Re: Touch scrolling after preventDefault called on first touchmove event

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


> A little clumsy and can use some wordsmithing, but technically accurate I
> think.
>
> - Cathy.
>
> >
> >
> >> Tim
> >>
> >>> On Thu, Jul 17, 2014 at 4:53 PM, <cathy.chan@nokia.com> wrote:
> >>> I'm not sure I understand the meaning of "If every touchmove event of
> an active touch point is cancelled". To make the conclusion that *every*
> touchmove event is cancelled, the UA would have to wait until *all*
> touchmove events have been triggered and cancelled, which does not make
> sense.
> >>>
> >>> Perhaps what you really mean is that "If *any* touchmove event of an
> active touch point is cancelled, it should prevent any default action
> caused by that touchmove event, such as scrolling." But that's pretty much
> what preventDefault generally means. If that's indeed the case, maybe we
> don't need that sentence at all.
> >>>
> >>> From Section 8 Glossary:
> >>>
> >>> [[preventDefault
> >>>     If a event is cancelable, the preventDefault method is used to
> signify that the event is to be canceled, and any default actions defined
> in the user agent as a result of this event, or consequential events from
> the canceled event will not occur. Calling this method on non-cancelable
> events will have no effect. ]]
> >>>
> >>> - Cathy.
> >>>
> >>>> From: tdresser@google.com [mailto:tdresser@google.com] On Behalf Of
> ext Timothy Dresser
> >>>> Sent: Thursday, July 17, 2014 12:46 PM
> >>>> To: Rick Byers
> >>>> Cc: Kornel Lesi?ski; public-touchevents@w3.org
> >>>> Subject: Re: Touch scrolling after preventDefault called on first
> touchmove event
> >>>>
> >>>> I've updated the v1-errata branch of the spec to reflect this change.
> >>>>
> >>>> The diff can be seen at
> https://dvcs.w3.org/hg/webevents/rev/e52f9e5c93cd.
> >>>>
> >>>> The updated version of the spec can be seen at
> https://dvcs.w3.org/hg/webevents/raw-file/v1-errata/touchevents.html#the-touchmove-event
> .
> >>>>
> >>>> Please let me know if you have any feedback,
> >>>> Tim
> >>>>
>