Re: Should pointerId be an integer?

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