RE: Should pointerId be an integer?

I agree that integers are not likely to be a significant problem in practice. It's probably even less of a problem than for Touch Events because multiple device types could be in play, reducing the usefulness/significance of id selection algorithms like the "contact counter" approach.

I find the integer approach a bit more straightforward and flexible to use In particular, I often use them as keys. There was discussion about having an opaque object with some custom toString() value so that it could be used as a key--but then I think those string values could then have the same assumptions risk as integers.
 
For those wondering how the values are chosen in IE10, they  just come straight from the OS.  The fact that 1 is reserved for mouse is an artifact of that, and so I guess it could be considered an implementation detail. The algorithm the Windows 8 OS uses is:

- Mouse gets 1
-All other devices get assigned values 2-65535. Each newly detected pointer gets the next sequentially available value in this range, wrapping around when the maximum is reached. 
-All applications (windows) share the same pool of values. So it's not guaranteed that a web page would always see sequential values.

The last point is interesting WRT this discussion as it makes ID selection less predictable by pages in IE10. Other UAs could do something similar, for example share the same pool across browser tabs. Only when your selection algorithm introduces some new information otherwise not provided, like contact count, does this really become an issue (and a minor one at that, because web devs generally care about cross-browser interop). Perhaps just a non-normative author note could be provided, like "The pointerId selection algorithm is implementation specific. Therefore authors cannot assume values convey any particular meaning other than an identifier for the pointer that is unique from all other active pointers. As an example, values are not guaranteed to be monotonically increasing."

-Jacob


On Wed, Feb 20, 2013 at 1:49 PM, Rick Byers <rbyers@google.com> wrote:
>
> On Wed, Feb 20, 2013 at 1:44 PM, Daniel Freedman <dfreedm@google.com> wrote:
>>
>> Ordering of the pointers can be important for application specific code. For example, in a simple game, the first pointer could be used for directional control, and the second for performing actions.
>> Now, I'm not advocating that PointerEvents have a pointerId that is in a specific order, but rather knowing the order of when pointers appeared on the screen can be useful.
>> In the method I specified, ordering can be achieved with either integers or opaque identifiers.
>
>
> Except that with integers a page could make the assumption that start-order and numerical-order match (as would probably be the case in some implementations).  With opaque identifiers there's no such accidental assumption to be made.
>
> Note that if pages make an assumption about re-use, then that could (depending how we define it) still be a problem with opaque identifiers.
>
>>
>>
>> On Wed, Feb 20, 2013 at 12:43 PM, Alex Russell <slightlyoff@google.com> wrote:
>>>
>>>
>>> On Feb 20, 2013 8:31 PM, "Daniel Freedman" <dfreedm@google.com> wrote:
>>> >
>>> > I don't think that there is really much difference in using an opaque identifier vs an integer. In either case, a developer wanting to track the ordering of pointers will use an Array to hold the ordering, with .push for additions, and splice(indexOf(pointerId)) for removals.
>>>
>>> If they're just objects, where object identity is the only way to distinguish them, what is ordering for?
>>>
>>> > In the scenario with opaque identifiers, would users be able to put expandos on the identifier? That would be the only difference I could think of then.
>>> >
>>> > I agree that this is unlikely to be a huge issue.
>>> >
>>> >
>>> > On Wed, Feb 20, 2013 at 12:10 PM, Rick Byers <rbyers@google.com> wrote:
>>> >>
>>> >> There's a lot of different things in Alex's e-mail, so it might help to break this up.  Here let's talk just about the semantics of pointerId.  Why is it defined as an integer, and why is the value '1' reserved for mouse?
>>> >>
>>> >> I've seen some (rare) problems with the touchID in TouchEvent due to differing semantics.  In particular, iOS uses a monotonically increasing count, and Chrome uses a contact counter (eg. touch, release, touch is ID #2 on iOS, but #1 on Chrome).  This causes, for example, my silly paint test application (www.rbyers.net/paint.html) to behave differently on the two platforms (it uses a dumb heuristic to color each active touch differently).
>>> >>
>>> >> For this reason, I like Alex's suggestion of making pointerId an opaque identifier rather than an integer.  Alex, Is there precedent for that pattern elsewhere?  I don't think this is likely to be a significant problem in practice, so I'm loathe to do anything too weird or surprising - it's not clear the small benefit would justify doing something more conceptually complicated.
>>> >>
>>> >> Thoughts?
>>> >>   Rick

Received on Monday, 4 March 2013 00:38:20 UTC