Re: Should touchmove really always be synchronous and cancellable?

Thanks guys!  We talked with Matt Brubeck (former TouchEvents spec editor)
on the Pointer Events call and he agreed this was indeed a bug in the spec
and we should change it.

So should I just propose the exact text of the change here in e-mail and
leave the doc work to you Doug (which the community could then review)?  Or
is there some system for me to directly do the doc work, even though it'll
be published by W3C staff?

Here's a rough overview of how I think the spec should change (based on my
analysis of existing popular mobile browsers).  This probably boils down to
a few different spec changes across section 5, but we can worry about the
precise text changes once we have consensus on the high-level (and the
process to make those changes).

touchstart, touchmove and touchend should all support both sync and async
dispatch (see http://www.w3.org/TR/DOM-Level-3-Events/#sync-async for
definitions), subject to the following rules.  Synchronous events are
always cancelable.  The touchstart event for the first touch point, and
it's first touchmove event are always synchronous (and so cancelable).  If
a touchpoint's touchstart is canceled, then all subsequent events for that
point will be synchronous.

One issue is exactly what to say about the cancelability of async events.
 In practice it appears that implementations today ignore peventDefault on
async touch events, but they (except for bleeding edge Chrome) don't
explicitly indicate this by setting cancelable=false.  Personally I
consider this an implementation bug (such events are conceptually
uncancelable but not indicated as such).  Perhaps we should file bugs
against the other browsers, and if another updates to match Chrome here
(setting cancelable=false), then we can spec it that way?

It may seem surprising that touchstart and touchend can sometimes be async.
 I don't think we need to get into the details in the spec (except perhaps
in a non-normative note), but for the sake of discussion here's the
justification.  First, for touchstart, if scrolling is in progress and a
second finger goes down (eg. to start a pinch), the pinch (and any
subsequent scrolling, whcih is visible to JS) isn't necessarily going to
block waiting for the results of that touchstart end.  For touchend during
a scroll, a fling isn't going to block waiting for the results of the
touchend event.

Thoughts?

Rick



On Thu, May 8, 2014 at 10:14 AM, Arthur Barstow <art.barstow@gmail.com>wrote:

> On 5/7/14 4:04 PM, Doug Schepers wrote:
>
>> Hi, Rick–
>>
>> If you decide that 'touchmove' should be async and uncancelable, we
>> should update the spec. It's important that the spec reflects the reality
>> of implementations.
>>
>> To drill into trivial process details, we should issue an errata document
>> that corrects this, and probably publish an updated version of the spec.
>> The catch here is that the Touch Events spec is an "orphan"... that is, the
>> Touch Events WG is now closed. But that's not a problem; W3C staff (in this
>> case, me) will publish the errata document, and I can also create a new
>> "Proposed Edited Recommendation" (PER) draft of the spec based on those
>> errata; we can add a notice to the top of the spec to tell people where to
>> look for the errata and newest version.
>>
>> W3C management was pretty open to the idea of Community Groups helping
>> maintain errata for orphaned specs; CGs can't publish normative documents
>> on the Recommendation track, but they can request that W3C staff publish
>> errata and PERs, and patent commitments don't change [1], so for minor
>> changes, we don't need to have a formal Working Group.
>>
>> (We plan to make this more clear in the new proposed Process Document,
>> BTW.)
>>
>> In any case, let's take whatever steps you think are helpful in making
>> the Touch Events spec both accurate and discoverable to readers.
>>
>
> Yes, agree.
>
> FYI, the Touch Events REC already includes a link to an errata document:
>
> <http://www.w3.org/TR/2013/REC-touch-events-20131010/REC-
> touch-events-20131010-errata.html>
>
> Doug - may we use the existing hg repo for diffs/patches? (I don't know if
> the write permissions were turned off when the Web Events WG was closed.)
>
> <https://dvcs.w3.org/hg/webevents/>
>
> -Art
>
>
>
>
>> [1] http://www.w3.org/2003/12/22-pp-faq.html#edlicensing
>>
>> Regards-
>> -Doug
>>
>>
>> On 4/14/14 1:23 PM, Rick Byers wrote:
>>
>>> Hi,
>>> http://www.w3.org/TR/touch-events/#list-of-touchevent-types says that
>>> touchmove is synchronous and cancelable. However many browsers
>>> sometimes choose to send touchmove asynchronously and ignore calls to
>>> preventDefault. For example, both Safari and Firefox send touchmove
>>> events async (with Event.cancelable=true) during scrolling but then
>>> ignore calls to preventDefault - eg. continuing to scroll freely. See
>>> [1] for details and tests. Do you agree that such UAs technically no
>>> don't conform to the spec here?
>>>
>>> Assuming there was some easy vehicle for publishing updates to the
>>> TouchEvents spec, would we want to relax this to give UA's the freedom
>>> to send touchmove async and set cancelable=false?
>>>
>>> In the interim (or absence), should UAs that choose to violate the spec
>>> and send touchmove async ideally set cancelable=false to make it clear
>>> to the application that they can no longer suppress scrolling? I've
>>> seen this cause a bunch of confusion which manifests itself on Firefox
>>> as "the double handling problem" where touching and dragging on a page
>>> causes some page action AND scrolling to occur at the same time (eg.
>>> perhaps the page was waiting until some offset was exceeded to test
>>> direction and decide whether to suppress scrolling and perform their
>>> action).
>>>
>>> I ask because we're continuing to explore [2] relaxing chromium's unique
>>> (and somewhat draconian) touchcancel on scroll behavior. If we are
>>> going to send some touch events async I believe we should set
>>> cancelable=false to make it possible for apps to understand the
>>> difference.
>>>
>>> [1]
>>> https://docs.google.com/a/chromium.org/document/d/12k_LL_Ot9GjF8zGWP9eI_
>>> 3IMbSizD72susba0frg44Y/edit#heading=h.nxfgrfmqhzn7
>>> [2] http://crbug.com/346693
>>>
>>>
>>
>>
>>
>