Re: [w3c/gamepad] Move vibrationActuator to the main spec (PR #190)

@nondebug commented on this pull request.



> @@ -153,6 +153,7 @@ <h2>
           readonly attribute GamepadMappingType mapping;
           readonly attribute FrozenArray&lt;double&gt; axes;
           readonly attribute FrozenArray&lt;GamepadButton&gt; buttons;
+          [SameObject] readonly attribute GamepadHapticActuator? vibrationActuator;

The Chromium implementation made it nullable for feature detection. Null `vibrationActuator` means no vibration capability.

It's odd that we now have two levels of feature detection and thus two ways to represent a gamepad with no vibration capability. To make feature detection simpler, the spec should pick one representation.

We should avoid breaking existing apps that use the null-check for feature detection. Making `vibrationActuator` non-nullable would cause these apps to play effects on gamepads that don't support any effects. That might be okay depending on how unsupported effects are handled.

According to the spec, `playEffect` called with an unsupported effect type returns a promise rejected with NotSupportedError. The actual behavior in the Chromium implementation is to resolve the promise with "not-supported". My guess is applications aren't checking for either of these. In the no-vibration-capability case, unexpectedly rejecting with NotSupportedError is probably more disruptive to existing applications than unexpectedly resolving with "not-supported". I think it would be reasonable to make `vibrationActuator` non-nullable if we also change `playEffect` to resolve to "not-supported" in this case.

If we decide to keep `vibrationActuator` nullable then the spec should require it to be null whenever `effects` would be empty.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/pull/190#discussion_r1406956701
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/pull/190/review/1751704322@github.com>