We discussed this last week and settled on the following request:

Given the proposal to obsolete the Vibration REC and 2 browser engines' reluctance to implement it, we wonder if there's another direction that could attract more interoperability. For example, would enough use cases be served if browsers could treat the device they're running on as a gamepad (https://w3c.github.io/gamepad/#gamepadhapticactuator-interface)? We think it would help everyone evaluate this API if the WG would write an explainer for their current direction, including a list of use cases and alternatives that you've considered.

Thanks for your review!

We consulted the Gamepad API editor to understand whether it'd be feasible to repurpose the current Gamepad API to cater for the Vibration API use cases as suggested. In our discussion we concluded it is not possible. For details, please see the meeting minutes.

For considered alternatives, we've looked at HapticsDevice API proposal that targets haptic-enabled surfaces and gaming controllers. There are a few important areas where that API (that exists in an explainer form only?) differs materially from the Vibration API:

HapticsDevice API defines non-interactive haptic feedback as out of scope, tying haptics into the PointerEvent interface. The Vibration API allows non-interactive feedback after the user has interacted with the page once (sticky activation). Non-interactive feedback has use cases in both gaming and web apps where the feedback is delivered in response to some event happening, not just in response to user interaction that triggers a PointerEvent. Such use cases include e.g. a game where a character bumps into a wall or an app where a long-running process finishes followed by a vibration to inform the user.

Another design consideration where the two APIs differ in a use case impacting way is that the HapticsDevice API supports implementation-defined waveforms (aka Pre-Defined Waveforms) while the Vibration API supports on-off pulses only. The latter provides a consistent experience across platforms, while the former as implementation-defined provides consistency within a one native platform only, but not across multiple platforms.

(We're aware of interesting experiments that create more complex waveforms using the Vibration API on-off pulses as low-level primitives to demonstrate feasibility of consistent waveform generation across platforms. This lowering approach follows the EWM principles.)

Since the Vibration API predates the explainer-era we did not have an explainer handy. We hope this comment addressed your questions and unblocks this review. I've filed https://github.com/w3c/vibration/issues/45 for the explainer and we'll incorporate insights from this review into that document. Thank you!

Hi @anssiko, thanks for being so proactive about engagement here.

The TAG looked at this in breakout and we have a few concerns:

We're concerned about the abuse of this API to divert attention in inappropriate situations. We note that you're specifying sticky activation. Are there use cases that support this - rather than transient activation?

For the difference in activation types, we think that sticky activation might not be a good justification for the notification-style use case. If someone isn't engaging with the site, having it vibrate could be annoying. If the goal is to generate a notification, the notification API seems like a much better fit for that. At least with notifications, people are in control of how they are notified (sound, visual, vibration, or combinations).

There is a good analogy between this and audio, in that both might be engaged in a similar way and disabled with similar controls. However, have you considered adding a stronger normative requirement that UAs should be able to turn it off? It's not as easy to turn off a vibration with physical controls as it is with sound.

Security/privacy considerations don't treat annoyance as a problem. Interruptions is a privacy issue you should consider addressing. We like that the vibrations only activate when the page is visible, but that seems like something that should be directly addressed as a mitigation for that issue. A transient activation requirement might help further.

Security considerations should require that accelerometers and gyroscopes are disabled for other origins when vibrating.

Thanks for your careful review of this API! To quickly answer the question while you're breakout-ting:

We note that you're specifying sticky activation. Are there use cases that support this - rather than transient activation?

I believe the following and other similar use cases do require a sticky activation:

Non-interactive feedback has use cases in both gaming and web apps where the feedback is delivered in response to some event happening, not just in response to user interaction that triggers a PointerEvent. Such use cases include e.g. a game where a character bumps into a wall or an app where a long-running process finishes followed by a vibration to inform the user.

That use cases suggests that maybe there is a state that exists between sticky and transient. That use case hardly ever involves a complete lack of interaction, but maybe ~4s (what I believe transient holds for) is not sufficient for that.

Edit to note that @hober suggests that maybe sticky activation might be fixed to reduce the potential for annoyance. For instance, deactivating it after any of: 30 minutes, sleep, the window losing visibility for more than 10s, etc.. (all numbers negotiable).

Thank you for resolving this review.

If an implementation wants to deactivate sticky activation to reduce annoyance, step 2 in the perform vibration algorithm provides an escape hatch for that. Examples provided by @hober are excellent.