Re: Should touchmove really always be synchronous and cancellable?

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.



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 Wednesday, 7 May 2014 20:04:45 UTC