Re: [DOM3Events] Identifying mouse events derived from touch events

On Wed, Jan 21, 2015 at 11:26 PM, Domenic Denicola <d@domenic.me> wrote:

> From: rbyers@google.com [mailto:rbyers@google.com] On Behalf Of Rick Byers
>
> > In the pointer events working group we had other reasons to want an
> input device API (eg. 'navigator' is really a poor place for
> 'maxTouchPoints').  Perhaps this is as good as a reason as any to start
> exposing an input device properties object.  I wouldn't argue here for
> hanging a bunch of extra stuff of it, but it's reasonable to think that
> over time we'll want an API surface like this.  Most other platforms have
> such a facility (eg. MotionEvent.getDevice() on Android).
>
> This seems pretty compelling. Especially given the prior art.
>
> It would be nice if someone were willing to sketch out a quick vision of
> what a future would look like with this idea fleshed out, e.g. I could
> imagine:
>
> - navigator.getInputDevices() => a (sorted?) list of them
> - some subset of the Android APIs at [1] on the InputDevice objects
> themselves
> - the ability to pointer-lock a specific device!?
>

Yeah, we'd probably also want APIs that mirror the interaction media
features <http://dev.w3.org/csswg/mediaqueries-4/#mf-interaction>,
eg. pointerGranularity and hoverType.  If there's agreement that this is a
preferable path forward for DOM events, then I can take a stab at sketching
something out. I know there's a ton of non-obvious issues that we could
rat-hole into, but if we'd be willing to have a sketch of where we might
want to head and then push forward on the simplest thing we need right now
(firesTouchEvents) then I'd be thrilled.

Even if we start small with a very simple TouchEvent.prototype.inputDevice
> that has a single property like "firesTouchEvents", it'd be helpful to have
> a vision for the future.
>

Note that it's MouseEvent.prototype we need this on, not
TouchEvent.prototype.  But perhaps we could safely put it on
UIEvent.prototype from the start.  Note that (for compatibility with user
expectations) Chrome and Firefox on Android fire only touch events for
mouse input, so it would be great to have some way to expose the true
properties of the source device for apps that want to opt-in to being aware
of the difference (just like native Android apps do).

Would event constructors then need a way to set it, or could JS-created
events always have a null sourceDevice.

I'd also be curious if we could learn from developers on other platforms.
> E.g., maybe MotionEvent.getDevice() is a universally hated API and all the
> Android developers in the world wish that Android had done something
> different? Or maybe they love it? That data would be nice.
>

I can see what I can find on the Android side.  I know the IE / Windows
teams have a ton of experience here too (Jacob and I have talked off and on
about such an API over the past couple years).

[1]: https://developer.android.com/reference/android/view/InputDevice.html
>