Re: [w3c/gamepad] id field in gamepad might have a persistent identifier? (#73)

> 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