Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Vibration API (Second Edition) #267

Closed
MrBrain295 opened this issue Oct 14, 2023 · 3 comments
Closed

Vibration API (Second Edition) #267

MrBrain295 opened this issue Oct 14, 2023 · 3 comments
Assignees
@marcoscaceres
Labels
concerns: annoyance The technology described in this proposal could be used to do things that may annoy the user concerns: device independence Proposal is hardware- or OS-specific, in a way that may risk the device independence of the Web concerns: integration Can't be used w/ other web platform features (or unclear what happens if used together) concerns: portability This proposal may be impossible or difficult to implement on at least one important platform concerns: power This feature may have negative impact on battery life concerns: use cases The use case for this proposal are not stated or are unclear position: oppose topic: device apis Spec relates to device APIs: access to device-specific hardware, sensors, and interfaces venue: W3C Devices and Sensors WG

Comments

@MrBrain295
Copy link

WebKittens

No response

Title of the spec

Vibration API (Second Edition)

URL to the spec

https://w3c.github.io/vibration/

URL to the spec's repository

https://github.com/w3c/vibration/

Issue Tracker URL

https://github.com/w3c/vibration/issues

Explainer URL

No response

TAG Design Review URL

No response

Mozilla standards-positions issue URL

mozilla/standards-positions#907

WebKit Bugzilla URL

No response

Radar URL

No response

Description

In their words "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 [NOTIFICATIONS] specification. In addition, determining whether vibration is enabled is out of scope for this specification."
@lukewarlow lukewarlow added topic: device apis Spec relates to device APIs: access to device-specific hardware, sensors, and interfaces venue: W3C Devices and Sensors WG from: Intel Proposed, edited, or co-edited by Intel. labels Oct 14, 2023
@marcoscaceres marcoscaceres self-assigned this Oct 18, 2023
@marcoscaceres marcoscaceres added concerns: annoyance The technology described in this proposal could be used to do things that may annoy the user and removed from: Intel Proposed, edited, or co-edited by Intel. labels Oct 18, 2023
@marcoscaceres
Copy link
Contributor

marcoscaceres commented Oct 18, 2023 •
edited

I think the problem with the API is exactly the one described by API itself, in that it's too simple:

  • It doesn't actually provide means to be tactually expressive (just a single pattern, which might be confusing or meaningless);
  • it's too susceptible to being abused as a notification mechanism - hence the concern about user annoyance.
  • it doesn't provide any description of what "vibrate" actually means, thus would lead to different "feels" across devices, platforms, etc. (concerns around device independence and portability)
  • And I guess it's subject to wasting significant power when used without care.

So it's not clear what the use case for this API is for or how it benefits users in a meaningful way.

@marcoscaceres marcoscaceres added concerns: use cases The use case for this proposal are not stated or are unclear concerns: portability This proposal may be impossible or difficult to implement on at least one important platform concerns: power This feature may have negative impact on battery life concerns: device independence Proposal is hardware- or OS-specific, in a way that may risk the device independence of the Web labels Oct 18, 2023
@marcoscaceres marcoscaceres added the concerns: integration Can't be used w/ other web platform features (or unclear what happens if used together) label Nov 1, 2023
@marcoscaceres
Copy link
Contributor

Discussed with colleagues internally and they also pointed out that it wouldn't even be possible to support this API on Apple's native platforms (concern: integration).

Taking what I already wrote above, and unless anyone from the WebKit community objects, we will be labeling this as "opposed" within a week or so.

@MrBrain295
Copy link
Author

@marcoscaceres could you please add the oppose label? Thanks!

@annevk annevk closed this as completed Nov 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@marcoscaceres marcoscaceres

Labels
concerns: annoyance The technology described in this proposal could be used to do things that may annoy the user concerns: device independence Proposal is hardware- or OS-specific, in a way that may risk the device independence of the Web concerns: integration Can't be used w/ other web platform features (or unclear what happens if used together) concerns: portability This proposal may be impossible or difficult to implement on at least one important platform concerns: power This feature may have negative impact on battery life concerns: use cases The use case for this proposal are not stated or are unclear position: oppose topic: device apis Spec relates to device APIs: access to device-specific hardware, sensors, and interfaces venue: W3C Devices and Sensors WG
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@marcoscaceres @annevk @lukewarlow @MrBrain295