Re: [w3c/uievents] Gamepad-specific DOM keys / location? (#79)

I agree that we should be looking at this bigger than just what browsers do today (which is to not support the gamepad navigation use case except via hacks).  The GamePad API makes sense for the gaming scenario, but for browsing with a GamePad, it's really just another input device which should be supported by the existing input APIs.

To clarify the concrete use case:
 - User agent wants to connect "button A" to certain default actions like navigating a link and clicking a checkbox
 - Developer should be able to override that behavior somehow if they want to customize the gamepad-driven experience
 - Button_A shouldn't necessarily have the exact same semantics as any existing keyboard event.  Eg. it shouldn't add any whitespace to a text field.

We've long handled more unusual input devices by just pretending they're something they're not.  Sometimes that's necessary for web compat (eg. touch screens generating mouse events in limited scenarios).  But subject to compat constraints I think in general we should strive to expose all the information available to the native platform.  I mean, if [TVSatelliteToggle](https://w3c.github.io/uievents-key/#keys-tv) isn't too niche to get a key value, then surely `GamepadButtonA` isn't either.

[Here's some details of the Android API](http://developer.android.com/training/game-controllers/controller-input.html#button) we're trying to expose here.  @alexelias any idea what the API on other OSes looks like?  If we're going to specify something here, there's the practical matter of figuring out how exactly to assign [code](https://w3c.github.io/uievents-code/) and [key](https://w3c.github.io/uievents-key/) values.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/79#issuecomment-218774597