Re: [wg/das] Vibration API (Second Edition) Specification as Obsolete Recommendation (Recommendation review)

The Council resolved to uphold the objection.

[[
The Council recommends that the DAS WG continue their work on the
Vibration API’s Candidate Recommendation Draft in accordance with the
publication process.

This Council encourages the DAS WG to address the privacy and security
concerns that initiated the obsoletion process. We recommend that the WG
document what implementation experience the API currently has. In the
next rechartering process for the DAS WG, we anticipate that some W3C
members will object to keeping a deliverable without a concrete plan and
timeline for shipping in multiple major browser engines. We have not
looked for consensus on that question in this Council, and we recommend
that the WG document the plan it thinks is best, whether or not that
plan includes implementation in multiple browser engines, and a
compelling rationale to help any reviewers decide whether the plan is
acceptable.
]]

The Vibration API (Second Edition), W3C Recommendation 18 October 2016,
remains as Recommendation.


See also https://www.w3.org/2025/08/vibration2-council-report.html

Philippe

On 2/10/2025 11:42 PM, Philippe Le Hégaret wrote:
> From:
>    https://www.w3.org/2002/09/wbs/33280/obsolete-vibration-api/results
> 
> [Member] is submitting a formal objection to the recommendation of 
> marking the Vibration API as obsolete. This recommendation would have 
> significant implications for the web ecosystem and the developers who 
> actively use this API.
> 
> The web ecosystem expands and improves when it is more capable, making 
> it a viable option for developers to build their apps on. Conversely, 
> when the capabilities of the web contract, this reduces the potential 
> for developers to build their apps with the web.
> 
> If the primary concerns are that the Vibration API has only a single 
> implementor, privacy issues, or that it should be part of another 
> specification, we believe these issues can all be addressed without an 
> obsolete recommendation. Specifically:
> 
> Single Implementor: Rather than deprecating the API, efforts should be 
> made to encourage broader implementation across different browsers and 
> platforms. If those implementors have concerns about the API itself, 
> those concerns should be brought to a community or working group, and 
> the specification can be updated.
> 
> Privacy Concerns: If there are privacy issues associated with the 
> Vibration API, these should also be addressed through enhancements and 
> safeguards within the API itself. We welcome opportunities to improve 
> privacy in API design.
> 
> Specification Integration: If the Vibration API would be better suited 
> as part of another specification, such as the Permissions API, this can 
> also be discussed in a community or working group while the current 
> Vibration API remains non-obsolete.
> 
> If a change is necessary, we recommend publishing as Note instead of 
> removing Recommendation status.
> 
> We advocate for iterating on API designs rather than marking them 
> obsolete. Doing so will allow the web ecosystem to grow and adapt 
> instead of shrinking and becoming less capable for developers.

Received on Monday, 8 September 2025 11:08:50 UTC