Update implementation report

[reillyeon]

https://github.com/w3ctag/obsoletion/issues/7 raises the concern that the current implementation report shows that Firefox supports the API while Mozilla has in fact removed (see bug 1653318).

The implementation report should be updated and without a second implementation this specification no longer meets the requirements for advancing to a W3C Recommendation and is thus a candidate for transition to an Obsolete Recommendation.

[marcoscaceres]

@egirard wrote:

Chrome does do a reasonable job of mitigating / blocking "troublesome" vibration calls. And the usage of this API remains extremely low.

Right, but the spec itself doesn't provide those mitigations. That's also my point: if one was to implement the "Recommendation", then users of that use agent would have a bad time on the web.

That's one of the many reasons why this shouldn't the a "W3C Recommendation"... recommending it is as is harmful to users and the Web.

In spite of the prevailing opinion, there remains a meaningful use case for haptics. For example, native apps have access to haptics in ios, macOS, android, and windows.

Absolutely. The utility of haptics as a UI affordance is not in question. It's the context and how the APIs are exposed and used that is, as well as the current form being "Recommended" by the W3C.

I don't have insight into how actively these APIs are used, but there are many examples of haptic feedback being used effectively in native apps. It would be unfortunate to limit web developers access.

Right, and that's not what's in question in this issue. As I mentioned, revisiting haptics in the appropriate context is in the purview of the Web Apps WG. See Gamepad API, for instance - or Microsoft's proposal

How it was done with the Vibration API is what's in question here.

[marcoscaceres]

@scheib wrote:

Yes, there are valid use cases.

Please understand that I'm not saying there are not.

I was just discussing a partner's needs which does use vibration. They established a large business as a web app, and I don't think we should force them away.

I don't think so either. What I'm arguing for is that:

1. We acknowledge that Vibration API was not the right design - it's too limited and was designed for a bygone era and now obsolete haptic hardware.
2. We acknowledge that the API is being abused/misused all over the Web, as evidenced by any site from Chrome status page. To the point where it works in maybe 1 or 2 of the 148 sites listed on the Chrome status page, and even then the use is questionable.
3. The basis for this being a Recommendation no longer holds (see implementation report) - so should be Obsoleted or have a different designation.
4. DAS is lacking the appropriate stakeholders to shepherd a new haptic spec.
5. There's little interest in exposing the Vibration API in its current form other engines.

So, again, I'm not saying let's not do haptics. I'm saying let's do haptics right, but also let's stop "recommending" Vibration as the solution. It's not fit for purpose and it's rife with abuse.

While some browsers may choose not to expose the feature I don't personally see the issue with this specification existing in the WG.

Unlike WebApps, the DAS Working Group is not charted to work on haptics. It is not in scope of the working group (so DAS can't work on it, unless they recharter). The working group is only chartered to do small/light maintenance on the Vibration spec, not add new features.

I'm not suggesting the W3C stop working on haptics. On the contrary, I'm suggesting that the work be done with a larger set of stake holders as part of WebApps or the WICG.

Marcos, your contributions are so valuable to so many specifications in need of material improvement. When you work on those I'm always grateful.

🥹 ... I appreciate that. And I'm well aware that this is a real low point in the relationship between myself and DAS.

At the same time, I do want all of us to do better here. All I ask is that we look at the evidence objectively, and, as @egirard did: call me out if I too am not being objective enough and let's dig into the details as appropriate - but please let's put the interest of end users first here.

[marcoscaceres]

@marcoscaceres, can you clarify why you think this is misuse? It is a common pattern in mobile games to use on-screen controls to emulate a gamepad, and haptics are a reasonable part of this.

Right, again, the validity of the use case is not in question. It is if the API is suitable to meet the use cases, and the implications that every website then has access to the API leading to all the abuse/misuse cases.

Please consider that it's possible to, for instance, on certain platforms to overlay a virtual gamepad controller on an application - and I believe it may be possible to do a similar thing on Android. Such solutions would provide a very specific, highly accessible, user controllable, developer customizable, virtual controller with haptics that could be provided by the Gamepad API or existing companion spec.

That's an entirely different approach to achieving the "I need a gamepad with haptics" use case, without needing to expose .vibrate() everywhere in a manner that is so highly abusable (again, as evidenced by the 148 sites).

This is very much akin to vibration for notifications: they are offloaded to the OS, giving ultimate control to the end-users if they want to turn those off or not, without as much user annoyance.

The approach of having a .vibrate() function accessible everywhere is problematic not just because it meets the use cases in an unsatisfactorily manner (e.g., no "rumble" or control of intensity and magnitude, just simple pulse whose intensity is not even specified) - but also because one needs to consider all the misuse/abuse cases that it enables.

So again, the question of "what use cases does it enable?" must always be paired with "what abuse cases does it enable?" and does the API enable more abuse/misuse than the use cases? (the answer is clearly "yes - more abuse cases")

I hope by now it's pretty clear, by looking at the sites that are using the Vibration API, that:

1. it's mostly used in an abusive manner
2. it doesn't meet the gamepad use case as well as maybe something like the Gamepad API could.

To use the Gamepad API for this would be strange since a mobile device would only provide the haptic portion of the Gamepad API.

Would it though? I'm just trying to show that there are multiple ways of solving for these use cases - and that falling back to .vibrate() feels a bit short sighted: just because .vibrate() does handle a little bit of the use case (limited haptics), the consequences for the rest of the ecosystem are demonstrably detrimental (the high rate of misuse/abuse).

Without getting into a discussion here, hopefully that shows that there might be different ways of approaching the gamepad-like haptics use case in a manner that is better for users and empowers developers to make great experience, while hopefully mitigating the abuse cases seen with the .vibration() API.

[marcoscaceres]

Put differently: adding more API surface as per #17 would not be a good approach. It would just further exacerbate an already demonstrably dire situation (extremely high rates of misuse of the API).

I think we should look seriously at what people might be legitimately using the API for via Github search, and then see if there's better ways of doing that without all the abuse cases.

And we should do that in a forum that includes more stakeholders.

[reillyeon]

@anssiko, any update on publishing a new implementation report?