Re: Should touchmove really always be synchronous and cancellable?

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:


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



> [1]
> Regards-
> -Doug
> On 4/14/14 1:23 PM, Rick Byers wrote:
>> Hi,
>> 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]
>> [2]

Received on Thursday, 8 May 2014 14:14:41 UTC