W3C home > Mailing lists > Public > public-pointer-events@w3.org > January to March 2013

RE: Distinguishing input from multiple users

From: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Tue, 26 Mar 2013 22:08:41 +0000
To: Rick Byers <rbyers@google.com>, Sangwhan Moon <sangwhan@iki.fi>
CC: "public-pointer-events@w3.org" <public-pointer-events@w3.org>, "www-dom@w3.org" <www-dom@w3.org>
Message-ID: <243126e621024e8e86200da00af1cd0b@BY2PR03MB028.namprd03.prod.outlook.com>
(Using this thread to follow up on my Action 30 from today's call)

We discussed this issue on today's call. There were several folks interested in this scenario. We agreed it wasn't necessary for PE V1 (which you also agreed below).
http://www.w3.org/2013/03/26-pointerevents-minutes.html#item05

Additionally, one point discussed (for which there was additional support from Olli Pettay and Rick Byers) is that this likely isn't a problem unique to Pointer Events. For example, there may be multiple keyboards and you wish to differentiate keyboard events by user. Our recommendation is that this instead be considered for UIEvent and not PointerEvent. The current UIEvents spec being produced by the Web Apps group is probably the right place to propose that.

One concern we should be careful of is to ensure that this deviceId cannot be used to track users across pages.  So while the property can differentiate between multiple users of the same application, a given user's ID should not persist across page navigations. Perhaps to be clearer on that behavior, a name other than "ID" is appropriate. For example, maybe "deviceIndex".

I've added www-dom to this thread for their consideration.

-Jacob

From: Rick Byers [mailto:rbyers@google.com]
Sent: Tuesday, March 26, 2013 1:50 PM
To: Sangwhan Moon
Cc: public-pointer-events@w3.org
Subject: Re: Distinguishing input from multiple users

Thanks Sangwhan.
I do think we  should do something here, probably combined with enumeration/query APIs (eg. how many touchscreens are there, and how many contacts do each support).  It's not clear to me how we'll want to do this in full - eg. a deviceId on the PointerEvent and then additional APIs that operate on device IDs, or an API for looking up the device ID for a pointer ID.  So my preference would be to defer to v2, but I don't have strong feelings about it.

For the WiiRemote scenario, would you expect it would use a custom pointerType, and would each 'device' have exactly one pointer?  If so, then it seems like an app would need to know that for your pointerType, each pointer is a distinct user (in contrast to touch for example), and having deviceId wouldn't add much, would it?  Multi-user multi-pointer input would definitely be a problem though.  Or maybe the problem is that you'd want sites to work without knowing about Wii remotes in particular - if so I'm not sure how that would work.

Rick


On Tue, Mar 26, 2013 at 9:03 AM, Sangwhan Moon <sangwhan@iki.fi<mailto:sangwhan@iki.fi>> wrote:
Just to clarify - sorry for not being explicit, this is not a LC comment - nor do I think this should be a v1 showstopper. The added complexity just to get the device ID right on all platforms is probably not worth the hassle to be forced into v1.

The specific use case I had in mind was for HTML games on a console (or PC, TV) - as I've seen a [1] workaround implementation possibly due to the very reason that there wasn't a standard that could be readily used.

(Although as with all software "let's do it later" also tends end up being "let's not do it ever", but let's imagine that won't happen)

The [2] Gamepad API has this concept - although it's a bit more complex - but it shares the idea.

--
Sangwhan Moon

[1] http://my.opera.com/Vital/blog/the-wii-remote-api
[2] https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html


On Tuesday, March 26, 2013 at 11:55 PM, Rick Byers wrote:

> Sangwhan, can you elaborate a bit on the scenario you see this being useful in? Adding a deviceId to the event (or some other mechanism to correlate pointers to devices and get information about those devices) seems like it could be handy, but I'm wondering if this is something we'd really want to try to get into v1.
>
> No existing input API has this, right? Are there examples of real-world sites that are hurting as a result?
>
> Thanks,
> Rick
>
>
>
> On Mon, Mar 25, 2013 at 7:29 AM, Scott González <scott.gonzalez@gmail.com<mailto:scott.gonzalez@gmail.com> (mailto:scott.gonzalez@gmail.com<mailto:scott.gonzalez@gmail.com>)> wrote:
> > I like the idea of having a device id associated with each event. I've also heard requests to be able to listen for when a device is connected/disconnected.
> >
> >
> >
> > On Sun, Mar 24, 2013 at 1:54 AM, Sangwhan Moon <smoon@opera.com<mailto:smoon@opera.com> (mailto:smoon@opera.com<mailto:smoon@opera.com>)> wrote:
> > > In the specification as of today, there is no reliable way to detect/associate
> > > input from multiple users - as PointerEvent.pointerId is the closest thing that
> > > can be used to detect such a thing, which sadly doesn't guarantee a reliable
> > > pointerId to user mapping.
> > >
> > > I see two approaches for resolving this:
> > >
> > > 1) Re-define PointerEvent.pointerId in a way that:
> > > - How indices are generated and reserved for non-mice is normative, so it
> > > can heuristically map to a specific input device.
> > > - Indices are not recyclable.
> > >
> > > (and possibly add the concept of "available pointers", or redefine "active pointers")
> > >
> > > 2) Add a new deviceId member in the PointerEvent interface.
> > >
> > > (and possibly add methods to enumerate available devices)
> > >
> > > I'm not sure which would be the best way to handle this, although I am a bit
> > > skeptical about the first idea as detecting the device will possibly leave corner
> > > cases where the heuristics may fail.
> > >
> > > --
> > > Sangwhan Moon, Opera Software ASA
> >
>
Received on Tuesday, 26 March 2013 22:09:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 22:09:49 GMT