I think this got spec'ed based on my prototype implementation and we never revisited it. Currently what Firefox does is put <USB vendor ID>-<USB product ID>-<Gamepad name> in the id property.

I wanted the product/vendor ID in there so that content could backfill mappings for controllers that don't provide a standard mapping. The name is nice to be able to present to the user, but not strictly necessary.

Do you have any suggestions for what would make the most sense here? I think maybe specifying that the id property should contain vendor id-product id if available is sensible, and perhaps we should split the name out into a separate name property.

Some things to consider:

1) You'd have to be careful about over-specifying the format to depend on signals that may not be present on all devices. For example: I don't think that Android would give you a vendor ID and product ID. XInput devices also don't provide many controller details unless you look at other APIs.

2) Not only could a controller be exposed differently between OSes, but the various browsers on the same OS may expose controller inputs differently. Assuming that ID strings were rigorously enforced across browsers in order to get a complete idea of how a controller is exposed you would then need to look at the id, the OS, and the browser as exposed by the User Agent string. :P The only time that the inputs will reasonably be the same across the board is if they have the mapping "standard", which _is_ well specced.

I think the only reasonable route for developers to take when presented with a controller that doesn't conform to the "standard" mapping is to have the user run through a quick configuration dialog and then save the mapping the users provides.

Brandon your comments make me feel that the ID should not be exposed to developers at all but instead have them rely  on "mapping" attribute. It seems the added benefit to developers of the ID does not out weigh the potential problems of the inconsistency of the IDs.

In an ideal world every joystick would have an appropriate mapping, but that simply can't realistically be the case. For instance: In Chrome at the moment giving a gamepad a standard mapping involves getting the gamepad into my hands and letting me make C++ changes to Chrome. Obviously that's not scalable, and is guaranteed to exclude much of the long tail of gamepads not made by Microsoft or Sony.

Having an ID allows users a basic method of capturing and using custom JS mappings, which is a worth cause in my mind.

I think we might be able to mitigate some of the "same controller doesn't map correctly across browsers" issue with more careful spec language.

I suspect the largest difference is handling things like directional pads, which are often represented as neither buttons nor axes (DirectInput and HID often calls them "hat switches"). We could add spec language to indicate how those ought to be mapped to buttons/axes which might be enough to smooth out the cross-browser differences.

There's still likely to be differences across OSes, unless we get every implementation using raw HID input on every OS, and I'm not sure if that's feasible, or if there's a way around that.

Moved to https://github.com/w3c/gamepad/issues/9