Re: Encourage more consistent semantics of Touch.identifier?

While not a TouchEvent, I believe that Microsoft always assigns an
pointerId of 0 when a PointerEvent is triggered via a mouse. It's probably
worth considering the impact of this since if the Microsoft behavior
becomes standard then apps will need to handle this case in the future
anyway.

I'll need to double check this when I'm home and have access to my tablet.


On Thu, Sep 6, 2012 at 9:54 AM, Rick Byers <rbyers@google.com> wrote:

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