- From: Christopher Robert Van Wiemeersch <notifications@github.com>
- Date: Mon, 04 Mar 2019 19:04:21 -0800
- To: w3c/gamepad <gamepad@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/gamepad/issues/73/469517729@github.com>
> It might also make sense to have `id` (or corresponding broken out fields for descriptor/name and the vendor and product identifiers) as an optional field, if it's needed for certain use cases where a site wants to provide customized functionality for users with particular hardware. I like this. > And where an implementation doesn't want to or can't provide detailed vendor/serial information or can't provide a useful human-readable name, we should prepare sites using the API for those fields not to be present. I agree. I think it probably makes sense to remove the `id` [language from the spec](http://w3c.github.io/gamepad/#dom-gamepad-id) and from the [WebIDL schema for the `Gamepad` object](https://github.com/w3c/gamepad/blob/361e37a/index.html#L195). On a related note, for the [WebXR APIs](https://github.com/immersive-web/webxr), there's a proposal for maintaining a [system of gamepad mappings](https://github.com/immersive-web/xr-gamepad-mappings#overview) (which is more relevant for issue #7), which I bring up because the proposal is to key off the `Gamepad#id`. I propose we remove `id` and if absolutely necessary we could add `vendor` and `productId`. For reasons explained in comments above, ideally web developers and frameworks do not sniff for `Gamepad#id` (or a possible `Gamepad#vendor` + `Gamepad#productId`) but instead use feature detection of gamepad mappings and support inferred from `Gamepad#buttons`, `Gamepad#axes`, etc. -- 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/gamepad/issues/73#issuecomment-469517729
Received on Tuesday, 5 March 2019 03:04:44 UTC