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
Hi.
TouchEvents v1 defines
Touch.identifie<http://www.w3.org/TR/touch-events/#widl-Touch-identifier>r
as:

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
point<http://www.w3.org/TR/touch-events/#dfn-active-touch-point>.
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
elsewhere.

Thanks,
   Rick
Received on Thursday, 6 September 2012 13:55:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 September 2012 13:55:50 GMT