Gamepad API Trigger-Rumble Haptics Extension about standards-positions HOT 13 CLOSED

I'm personally opposed to this proposal (i.e., this position is NOT representative of the WebKit community; I'm posting it as input while waiting for further input from WebKit community members).

Although I'm are generally supportive of enabling haptic feedback, such as "trigger-rumble", on gamepads, I have significant reservations about the (non-standard) GamepadHapticActuator interface on which this proposal relies.

Specifically with the "trigger-rumble" proposal, I'm concerned that it’s targeting a narrow set of hardware. To alleviate this, it would be good to provide a canonical representation, such as an audio file, that can be used to consistently emulated "trigger rumble" across generic gamepads.

Returning to GamepadHapticActuator (and the changes that result directly from adding "trigger-rumble"), I've provided feedback on the design of the API via the W3C and outlined several issues. Some of the issues also appear in the "trigger-rumble" proposal (particularly around .canPlay()).

Lastly, I'm are sympathetic that GamepadHapticActuator has been shipping in Chromium-based browsers for a while despite the API not being a published standard. This situation is quite unfortunate and something the implementers should try to remedy through collaboration at the W3C: the more developers come to rely on the design of GamepadHapticActuator, the higher the chance that the Web Platform will be stuck with it.

I would be open to exploring alternatives to the GamepadHapticActuator, or evolving GamepadHapticActuator into something more useful - as well as looking at how we can enable more haptic effects on gamepad devices.

from standards-positions.

Thanks @marcoscaceres
Our newest controller doesn't just have frequency; it's even possible to play music using a special motor.

We don't have an immediate need to have support for this but it would be nice to have in the future.

from standards-positions.

Changed position to support, as we collaborated in the specification over in WebApps and implement this.

from standards-positions.

I think @beidson & @marcoscaceres have opinions here.

from standards-positions.

Discussed with other folks and our position remains the one I posted above (#1 (comment))... basically, gamepad haptics are good, but we have concerns about GamepadHapticActuator. Marking as opposed for now, but happy to continue the discussion at the W3C.

from standards-positions.

As mentioned earlier, the quest browser is exposing haptics and they're use quite a bit by developers.
We just released a new controller that has 3 sets of haptic actuators and each also support frequency.

The main actuator also support audio samples so it could play music or other effects. Was this ever discussed?

from standards-positions.

The main actuator also support audio samples so it could play music or other effects. Was this ever discussed?

Yes. The W3C was waiting on a proposal from Microsoft to allow playing audio files:
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/HapticsDevice/explainer.md

I'm hoping they will move that to the WICG (if they haven't already).

from standards-positions.

@marcoscaceres what is the status of haptics? Would it make sense to join the CG or WICG?

from standards-positions.

@cabanier, sorry I missed your question. It's still unclear if/where further haptic-related work will happen at this point. A few of us are discussing it as part of WebApps WG, but we are unsure of a venue. It will more than likely be a WICG thing.

In other news, although WebKit were opposed to this API, the vibratorActuator did end up getting implanted in WebKit and shipped in Safari Tech Preview 163 (release notes). The API has been around for a while in Chromium browsers, so it kinda made sense to ship it for web compat... even though we all agree that the design is less than ideal.

At the same time, folks involved with the Gamepad spec don't seek to pursue haptics using above model further... so we will try to figure out where, how how, we go forward from here with something better/more scalable, that better supports the capabilities of newer gamepads.

from standards-positions.

Closing as we've identified our position.

from standards-positions.

@hober what do you think of my proposal in w3c/gamepad#186?

from standards-positions.

Reopening it on request of Chromium/Microsoft folks. I'll coordinate with @gabrielsanbrito on this.

from standards-positions.

Hey @marcoscaceres, I have updated the explainer to match the latest version of the Gamepad API spec.

from standards-positions.