W3C home > Mailing lists > Public > public-webevents@w3.org > July to September 2012

Encourage more consistent semantics of Touch.identifier?

From: Rick Byers <rbyers@google.com>
Date: Thu, 6 Sep 2012 09:54:53 -0400
Message-ID: <CAFUtAY-4CeP8hWe-zHDDM0ahzZH=db7QhD+fDvkUtLtzEgqX1g@mail.gmail.com>
To: public-webevents@w3.org
TouchEvents v1 defines

identifier of type long, readonly An identification number for each touch
point <http://www.w3.org/TR/touch-events/#dfn-touch-point>. When a touch
point becomes active, it must be assigned an identifier that is distinct
from any other active touch
While the touch point remains active, all events that refer to it must
assign it the same identifier.
*No exceptions.*
This leaves a lot of freedom to the implementation.  In particular, in
Chrome we use the current touch count starting at 0 (i.e. touch, release,
touch, release has identifier=0 in both cases).  Mobile safari appears to
use a global counter of some sort (eg. the same sequence will have
identifier=x and x+1 for some x).  What do the other browsers do?

It's possible (though clearly "wrong") for applications to behave
differently as a result of these different implementations.  Eg. I didn't
appreciate in advance the impact this difference would have on a simple
touch test program I wrote http://www.rbyers.net/paint.html (though in
retrospect it's obvious).  Is anyone aware of this difference impacting any
real-world apps?

In general I prefer specs to over-constrain things like this to minimize
the chance of app compatibility problems.  Any chance we'd be willing to
encourage or require (eg. in a later version of TouchEvents) a more
specific behavior?  We're willing to change Chrome (desktop and Android) to
use the global counter approach instead if it'll result in better
cross-browser consistency.  Then again, if no real-world app has actually
been affected by this, then it may not be worth the effort.  There may also
be even greater opportunities to improve cross-browser consistency

Received on Thursday, 6 September 2012 13:55:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:54 UTC