Re: [w3c/gamepad] Add vendorId, productId, name attributes (PR #202)

> Fortunately there are a few well-defined button mappings, so wonder we could have a proper API to expose that info, perhaps with an enum.

Button mapping isn't equivalent to deducing button labels. Console gamepads often have the same layout but with different labels. It's important for applications to be able to draw the correct labels even for gamepads with the same button layout and mapping. Suppose the game is trying to tell the player which button opens an options menu and wants the player to press the button mapped to buttons[9] ("right button in center cluster"). It's not enough for the game to know that this gamepad uses a PlayStation layout because the labels will differ depending on if it's a PS3, PS4, or PS5 controller. On [DualShock 3](https://en.wikipedia.org/wiki/DualShock#/media/File:DualShock_3.jpg) this button is labeled "Start", on [DualShock 4](https://en.wikipedia.org/wiki/DualShock#/media/File:DualShock_4.jpg) it's "Options", and on [DualSense](https://en.wikipedia.org/wiki/DualShock#/media/File:Playstation_DualSense_Controller.png) it's a hamburger icon. For the game to draw the correct label, the enum at minimum will need to distinguish between these possibilities. When a new PlayStation gamepad is released, it's likely that the spec would need to be updated with a new enum value.

We should try to avoid building this sort of dependency into the spec where the spec needs to be updated for each new device we want to support. Ideally it should be possible to connect your gamepad to your browser on the day the gamepad is released and have it work correctly without needing to wait for a spec change and a browser update. If we make it the browser's responsibility to maintain button label information then I expect there will be a delay before new gamepads are supported and less popular gamepads may never be supported.

Also, I think we should try to avoid referencing specific vendors or trademarks in the spec. If we added a enum with different values for "well-defined button mappings" then I expect the enum will include many trademarked names by necessity.

> But that means having IDs does not really solve the core problem?

The core problem (as I see it) is that applications are relying on the underspecified Gamepad.id attribute for programmatic identification of gamepad models. Applications already maintain mappings of Gamepad.id -> button labels. This makes it difficult to modify the Gamepad.id value for any currently-supported gamepad because it will break applications that rely on that gamepad having a stable Gamepad.id value. The purpose of the name attribute isn't to guarantee distinguishability, it's to provide the same level of human-facing distinguishability currently provided by Gamepad.id without requiring identifier stability.

> If it only helps when the user is having different type of controllers, I'm not sure how that would be helpful most of the time.

Do we need to consider whether it's helpful? I agree it's typically not necessary for users to identify a gamepad because usually there's only one connected gamepad, or all the gamepads are the same product model. However, the current API provides a human-facing identifier and application developers sometimes find it useful to present this identifier to users. I think we should assume that a human-facing identifier is helpful to application developers and empower browser implementations to provide the best possible identifier.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/pull/202#issuecomment-2125755083
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/pull/202/c2125755083@github.com>