Add features for Gamepad API #1835
Conversation
github-actions
bot
added
the
feature definition
features/gamepad-extensions.yml
Outdated
| @@ -0,0 +1,23 @@ | |||
| name: gamepad | |||
There was a problem hiding this comment.
| name: gamepad | |
| name: Gamepad extensions |
This suggestion is to make the name more consistent with other names in the repo, but I'm not very happy with it either because I don't think web game devs call it that. It looks like, from looking at MDN, that these extensions are only extensions because they came in another spec. But from a dev standpoint, they're just features of the Gamepad API.
It seems to me like we should make this feature specific to XR headsets' gamepads. Something like:
| name: gamepad | |
| name: XR headset gamepad support |
There was a problem hiding this comment.
The spec itself is called the "Gamepad Extensions", so that's why I elected to call it as such. It is true that these updates are tailored towards XR controllers, but looking at some of these interfaces, I could see them used for a non-XR gamepad. For example, the DualShock 4 and DualSense controllers have a gyroscope in them, which could be reflected through GamepadPose.orientation. They also have a touchpad, which could be reflected by GamepadTouch.
There was a problem hiding this comment.
Got it. Though our overarching goal is to design features around what developers would want to use in their apps, not around how specs are structured. So if a spec contains one set of interfaces for doing X, and another set of interfaces for doing Y, we would create 2 separate features: X and Y.
I think this is likely due to how we generated a bunch of the draft features, which we did by using a script that looped over specs.
From what you said, it seems like there could almost be one feature for gamepad XR headset support, one for gamepad orientation, and one for gamepad touch support.
What do you think?
Also pinging @ddbeck on this one, to help make a decision re splitting this feature.
| - api.Gamepad.timestamp | ||
| - api.GamepadButton | ||
| - api.GamepadButton.pressed | ||
| - api.GamepadButton.touched |
There was a problem hiding this comment.
This event is not supported in Safari yet. It's worth doing one of these two things:
- Either it's important enough (e.g. there are a lot of controllers that have touch-enabled buttons now) to warrant a separate feature tracking just that one event.
- Or we decide to keep it here (essentially ignoring it), in which case we need to add a comment saying why, so our future selves can remember.
| - api.Window.gamepadconnected_event | ||
| - api.Window.gamepaddisconnected_event |
There was a problem hiding this comment.
Same for these 2 BCD keys. They're not baseline, but since you can use the Gamepad API without them, we should ask ourselves whether they make sense as a separate feature, or if we keep them silent in here.
I'm not sure what to do here, because the tutorial on using the Gamepad API mentions those 2 events as essential to the feature: https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API/Using_the_Gamepad_API
The gamepadconnected event seems to be the main entry point to the feature.
Can you use the Gamepad API without these events?
Co-authored-by: Patrick Brosset <patrickbrosset@gmail.com>
Co-authored-by: Patrick Brosset <patrickbrosset@gmail.com>
This PR adds three new features related to the Gamepad API. The haptics-related features were split into their own subfeature, as not all browsers support haptics and the interface has changed for haptic feedback.