- From: Rick Byers <rbyers@chromium.org>
- Date: Thu, 22 Jan 2015 00:25:46 -0500
- To: Domenic Denicola <d@domenic.me>
- Cc: Anne van Kesteren <annevk@annevk.nl>, "www-dom@w3.org" <www-dom@w3.org>, "public-touchevents@w3.org" <public-touchevents@w3.org>, Jacob Rossi <Jacob.Rossi@microsoft.com>, Mustaq Ahmed <mustaq@chromium.org>
- Message-ID: <CAFUtAY_juG1ZjrC25bmdLATJazcKP-LBn5UQnVp8Kp0_WhJCJw@mail.gmail.com>
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 >
Received on Thursday, 22 January 2015 05:26:34 UTC