-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parts of section 3 should be moved to the Gamepad specification to avoid monkey patching #6
Comments
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. |
If that's the case, it's probably worthwhile to leave it open and assign it to CR? |
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. |
Happy to keep this open and flag as part of a future milestone. |
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.
paging @alice |
Looking at issue w3ctag/design-reviews#430 during the TAG F2F, the GamepadMappingType would benefit to become a registry, to allow other specification to add their own mapping types. |
See also whatwg/webidl#184. |
Also see w3ctag/design-principles#99 about |
This is already done https://www.w3.org/TR/gamepad/#dfn-xr-standard |
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.
The text was updated successfully, but these errors were encountered: