Parts of section 3 should be moved to the Gamepad specification to avoid monkey patching

[mounirlamouri]

The API adds an enum to the list defined by the Gamepad API. Ideally that new value should be added to the Gamepad specification directly as partial enum are not supported.

Also, the specification mentioned that the gamepads listed as part of a XRInputSource should not be listed in the gamepads available from the navigator object. This should also be mentioned in the Gamepad API ideally.

[toji]

Discussed this a bit with @bfgeek to get his perspective from an ergonomics standpoint. We both feel like the current approach in this spec module is appropriate for early stage spec development. Otherwise writing any spec that interacts with a more established web feature would require that spec's editors to accept experimental and potentially unstable text into the more mature document, which doesn't seem beneficial for either side.

It does seem entirely appropriate to normalize these enums/behaviors into the Gamepad spec once we've reached a more widely recognized stable state, like CR.

[NellWaliczek]

If that's the case, it's probably worthwhile to leave it open and assign it to CR?

[mounirlamouri]

As @NellWaliczek mentioned, we should keep this open.

But more importantly, we should reconsider even sending this to CR because if most of section 3 needs to be merged to the Gamepad API, the spec becomes a very tiny document that maybe should simply be in the main XR specification.

Ian is right that this is fine for an early spec but isn't for a mature spec.

[toji]

Happy to keep this open and flag as part of a future milestone.

[NellWaliczek]

Per our discussion with the TAG:

What is the appropriate way to handle enum values that are required by a specification other than the one that originally defined the enum?

We talked about a few different options but didn't come to a concrete conclusion. After further discussion with the Gamepad API folks, I'm still not entirely sure what the right approach should be. We've gotten several suggestions on how to go about this, but they all have different drawbacks and there doesn't appear to be consensus on the approach. Given that this isn't a problem unique to WebXR, we'd really love to get a more definitive answer from the TAG about which approach is best for web platform consistency.

• When the secondary spec nears CR, move nearly all references to the enum and its purpose into the original spec
• When the secondary spec nears CR, move the value to the original spec and point to the secondary spec for the explanation of it's purpose and use.
• Investigate adding partial enums to webidl
• Change the enum to be a DOM string

paging @alice

[ylafon]

Looking at issue https://github.com/w3ctag/design-reviews/issues/430 during the TAG F2F, the GamepadMappingType would benefit to become a registry, to allow other specification to add their own mapping types. That way, the xr-standard would still be defined in the WebXR Gamepad Module document and not in the Gamepad API where it doesn't fit.

[hober]

See also heycam/webidl#184.

[dbaron]

Also see w3ctag/design-principles#99 about partial more generally.

[Manishearth]

This is already done https://www.w3.org/TR/gamepad/#dfn-xr-standard