reillyeon
commented
5 months ago I would change "initially Mozilla" to "initially Mozilla (currently unsupportive)" to avoid misrepresenting their position.
Closed anssiko closed 5 months ago
reillyeon
commented
5 months ago I would change "initially Mozilla" to "initially Mozilla (currently unsupportive)" to avoid misrepresenting their position.
anssiko
commented
5 months ago Thanks @reillyeon for this clarification, updated the draft accordingly.
himorin
commented
5 months ago anssiko
commented
5 months ago Thanks again @himorin. I updated the draft with your suggestions. Since I'm not clear on Mozilla's rationale for the no-op decision, I used "presumably". If we unearth new information on the motive, we can update the TAG request after we submit.
anssiko
commented
5 months ago TAG review request has been submitted, so I'm closing this staging issue. Thank you for your feedback and comments.
For any additional comments, please use the official TAG review request you find from the tracker issue: https://github.com/w3c/vibration/issues/39
I'm requesting a TAG review of the Vibration API.
This specification defines an API that provides access to the vibration mechanism of the hosting device. Vibration is a form of tactile feedback.
The API is specifically designed to address use cases that require simple tactile feedback only. Use cases requiring more fine-grained control are out of scope for this specification. This API is not meant to be used as a generic notification mechanism. Such use cases may be handled using the Notifications API that has a normative dependency on this specification. In addition, determining whether vibration is enabled is out of scope for this specification.
Further details:
You should also know that...
Chrome shipped this API in 2013, following the initial implementation in Firefox in 2012. To prevent unintended use of the feature, Firefox made a change to its implementation in 2016 to gate the feature behind a permission prompt. During 2016-2017 Chrome solicited feedback from users and enabled user activation gating for the feature, first for third-party iframes only, then also for top-level, inspired by conceptually analogous web audio and video autoplay also gated by a user activation. Later, Firefox decided to make the API act as no-op, presumably due to inability to find a satisfactory explicit user consent mechanism, a decision predating user activation gating being incorporated into the specification.
Due to complexity of revising a Recommendation under the old process, TR for this specification did not receive these latest updates informed by implementation experience, but they were incorporated into the Editor's Draft instead. This caused some unfortunate confusion among readers not closely watching the specification. To clear this confusion, supported by reinvigorated interest and process improvements for revising a Recommendation, this API is now being revived on the Recommendation Track to allow bringing the updates from the ED back to TR and to allow for further improvements using the modern streamlined publication flow.
Since the latest published version the Working Group has gathered further implementation experience, added new privacy protections and improved reuse of definitions in other specifications.
The group decided to publish the specification as a new Candidate Recommendation Snapshot to bring updates that align with implementations from the ED to the TR.
Please see the commit history for details and the changes section for an overview of the changes since the latest published version. Diff between the latest published version and the staged snapshot is available at htmldiff.