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

Re: Encourage more consistent semantics of Touch.identifier?

From: Rick Byers <rbyers@google.com>
Date: Tue, 11 Sep 2012 12:08:23 -0400
Message-ID: <CAFUtAY8mYoT+GwQxrQmpUH8aGB6igEkL3JOKEZ=q8CV6jwA9sg@mail.gmail.com>
To: public-webevents@w3.org
Just to follow up based on the discussion in the WebEvents conference call:
the spec actually used to specify a particular algorithm (the one Chrome
has implemented), but a decision was made to relax it - so as to not
"over-constrain implementations":
http://www.w3.org/2010/webevents/track/issues/15 (and presumably allow the
spec to be consistent with the mobile safari implementation).

Personally, I prefer when specs constrain implementations to maximize
compatibility, but in this case I don't think it's important enough to
justify re-visiting this explicit decision.

We may still chose to change Chrome to match the mobile safari behavior
(since it's probably the most popular test environment for touchevents
today), but that's conformant with the current wording and so
mostly irrelevant here.


On Thu, Sep 6, 2012 at 10:17 AM, Scott González <scott.gonzalez@gmail.com>wrote:

> 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
Received on Tuesday, 11 September 2012 16:09:16 UTC

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