Re: Should pointerId be an integer?

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.


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
> >>
> >> On Tue, Feb 12, 2013 at 7:27 AM, Alex Russell <slightlyoff@google.com>
> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I had a chance to sit down with Rick Byers while he's been visiting
> London and review the current draft of the spec from a JS/layering
> perspective. What follows is are non-linear comments from the discussion.
> >>>
> >>> The spec should lead with examples, i.e., move Section 9 to where
> Section 2 is now.
> >>> pointerId is very strange. 3.1 suggests that mouses must have an ID of
> 1, but there's no other reasonable scenario for using integer values (what
> does zero mean? 30?). Having an opaque object instead feels like it'll
> satisfy the needs for identity comparison and for passing through to
> setPointerCapture()
> >>> I'm concerned about the extensibility storay (see below for a related
> discussion of the layering question): if someone plumbs a new, exotic type
> of input device through an OS and browser to the page, it's natural for
> pre-standards additions to the ecosystem to want to pass extra metadata
> along. The current spec doesn't have an advertised slot for "extra metadata
> goes here!". This is dangerous in the long-run as it suggests that the
> objects/events either shouldn't be extended (likely wrong) or extended on
> the event object directly, creating naming collision hazards later. I'd
> like to see an extraData slot specified on these event objects, defaulting
> to null, that can be used for this. When new pointer types
> become prevalent, this group can observe fields from these objects and
> standardize them in the primary event object.
> >>> The buttons field is painful as bitfield math is anything but natural
> in JS. That it's pre-existing on MouseEvent seems the only virtue. Consider
> this a note that users are likely to cringe, not an objection or suggestion.
> >>> The new touch-action CSS property seems to have conceptual overlap
> with the pointer-events property. If nothing else, the naming (and explicit
> callout to "touch" in the naming) creates huge ambiguity. Anyone who wants
> to allow some clicks through, but not dragging, is likely to find
> themselves wading through multiple properties who interaction is ambiguious
> at best. I haven't though hard enough about this to know if the properties
> can (or should) be merged, but it seems like an exercise the WG should
> attempt, if only to identify a strong argument against merging them.
> >>> navigator.maxTouchPoints seems deeply touch-specific. Also, is it
> dynamic? If I plug in a touchpad that support 5 or 6 (and I've only had 1
> or 2 before), what (if anything) happens? Also, isn't this a fingerprinting
> risk? Why not make this a property of the events to solve both?
> >>> Section 8 makes me terribly nervous that, for all the clarity in the
> introduction about the event funnel in the introduction, the WG does not
> have  firm conceptual model for wether or not the spec is describing a
> high-level or low-level event source. In particular:
> >>> Synthesizing mouse events, while possibly a reasonable thing to do in
> an event sink like the implicit controller that Pointer Events defines,
> seems to imply that mouse events are not a lower-level event type out of
> which pointer events are created.
> >>> The hover generation in 8.2 is particularly disturbing. If pointer
> events are conceptually a high-level synthesis of lower-level event sources
> (a filter, if you will), then perhaps there is room to generate high-level
> (synthesized) mouse events, but the MouseEvent spec conflates very
> low-level events (down, move, up) with high-level synthesized events
> (click, enter, out). To get some sanity here, splitting mouse (and other
> types of pointer) events into low-level synthesized events and specifiying
> how pointer events layer into this world seems like the only reasonable
> thing to do.
> >>> We may need to continue to specify that pointer events syntesize other
> sorts of events, but it should be possible to generate low-level events in
> JS and have Pointer Events synthesize these events for them too.
> >>> Thoughts?
> >>> Regards
> >>
> >>
> >
>