Intent to Implement and Ship: Vibration API

[Michael van Ouwerkerk]

Emails

Michael van Ouwerkerk (mvanou...@chromium.org)

Miguel Garcia (TL) (mig...@chromium.org)

Spec

http://dev.w3.org/2009/dap/vibration/

Summary

The Vibration API defines a means for web developers to programmatically provide tactile feedback in the form of vibration.

The Vibration API was already implemented by Samsung in February 2012 in WebKit but it is currently guarded: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/modules/vibration/

We intend to ensure the implementation is solid and then enable it without prefix.

Motivation

This will specifically support providing tactile feedback for improved accessibility. This feature can also be used to build more engaging mobile browser based games. We expect further use cases to be found. It is currently not possible to trigger tactile feedback in any other way.

Compatibility Risk

The compatibility risk is considered low as there is a mature specification and a shipping implementation in Firefox.

Vibration API demo page: http://jsbin.com/awecal/2

Firefox on Android already supports the unprefixed api, enabled by default: window.navigator.vibrate(pattern): https://developer.mozilla.org/en-US/docs/DOM/window.navigator.vibrate

Mozilla’s initial implementation of this feature was tracked in: https://bugzilla.mozilla.org/show_bug.cgi?id=679966

Apple has expressed some concerns, but did not provide much detail: https://lists.webkit.org/pipermail/webkit-dev/2012-January/019283.html

Microsoft’s position is currently unknown.

The Gamepad API does not currently mention vibration, but there might be an interest for extending this functionality: https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=222504

Row on feature dashboard?

Yes.

Requesting simultaneous permission to ship?

Yes.

[Gregg Tavares]

I have to ask, the spec says

"The API is designed to tackle use cases related to gaming, and is not meant to be used as a generic notification mechanism."

And yet the API exposed doesn't seem to relate to games. Current and last gen controllers have multiple motors with weights of different sizes. Spinning those 2 weights at different frequencies relative to each other is what produces the tactile feedback players are used to

Will this end up being a deprecated API once support for gaming vibration is added?

[Brandon Jones]

Many mobile games use vibration for player feedback, and I'm not aware of any phones with more than one motor, so this would be appropriate for that case.

It does feel odd to call this out as a gaming-targeted API though, and suggesting this is associated with gamepad vibration is probably misleading.

[Gregg Tavares]

On Fri, Apr 19, 2013 at 12:15 PM, Brandon Jones <baj...@google.com> wrote:

Many mobile games use vibration for player feedback, and I'm not aware of any phones with more than one motor, so this would be appropriate for that case.

Agreed. It's just that you'll need a new API for 2 motors and yet another API for multiple controllers.

[Joshua Bell]

FYI, this appears to be the Moz tracking bug for adding "rumble" to Gamepad:

https://bugzilla.mozilla.org/show_bug.cgi?id=680289

Unclear what direction they're headed is - I'll pester the assignee on IRC (turns out we're former colleagues).

[Joshua Bell]

... and from Kyle @ Moz, who's implementing this:

They're planning to keep these separate. The Vibration API's navigator.vibrate for the common case of simple notifications to the user, and a gamepad-specific API like MSFT's XInput's [1] for controlling pad-specific rumble w/ multiple motors.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/ee417001(v=vs.85).aspx#setting_vibration_effects

[ky...@nonpolynomial.com]

Hi. Mozilla dev currently assigned to gamepad rumble here.

So, as far as I understand it, we're probably going to keep gamepad haptics are part of the gamepad API, and the WebVibration API as simple standalong "on/off for a certain amount of time". WebVibration has a far larger usecase than gamepad rumble (since it's needed for typing, notifications, etc versus just gaming), and I don't believe most phones support variable speed vibration anyways (or at least don't expose access to it?).

That said, as you can see in the bug, the gamepad haptics api may look similar to the WebVibration API, resembling what microsoft's XInput system lets you do. How we'll address which motors to set and what the speed/time patterns will look like is undecided so far.

[Kostiainen, Anssi]

Hi,

[Chiming in as the editor of the W3C Vibration API spec.]

As mentioned in this thread already, the Vibration API was specifically designed to address simple use cases, and more fine-grained control required by Gamepad API is out of scope. Both can live peacefully on the platform, as they address different use cases.

What comes to the maturity of the spec, it has been shipping unprefixed since Firefox 16 (Oct, 2012). Relevant to this thread, earlier this week we discussed with Mozilla folks (Anne, Justin) on the opportunity to move away from throwing exceptions without breaking compatibility. Here's a pointer to the summary:

http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0044.html

I'll let you know earliest should this change get in to the spec.

Gregg - We'll clarify the introduction of the spec and remove the gaming reference. Thanks for pointing this out.

-Anssi

On Apr 20, 2013, at 12:39 AM, ky...@nonpolynomial.com<mailto:ky...@nonpolynomial.com> wrote:

Hi. Mozilla dev currently assigned to gamepad rumble here.

So, as far as I understand it, we're probably going to keep gamepad haptics are part of the gamepad API, and the WebVibration API as simple standalong "on/off for a certain amount of time". WebVibration has a far larger usecase than gamepad rumble (since it's needed for typing, notifications, etc versus just gaming), and I don't believe most phones support variable speed vibration anyways (or at least don't expose access to it?).

That said, as you can see in the bug, the gamepad haptics api may look similar to the WebVibration API, resembling what microsoft's XInput system lets you do. How we'll address which motors to set and what the speed/time patterns will look like is undecided so far.

On Friday, April 19, 2013 1:13:18 PM UTC-7, Joshua Bell wrote:
FYI, this appears to be the Moz tracking bug for adding "rumble" to Gamepad:

https://bugzilla.mozilla.org/show_bug.cgi?id=680289

Unclear what direction they're headed is - I'll pester the assignee on IRC (turns out we're former colleagues).

On Fri, Apr 19, 2013 at 12:21 PM, Gregg Tavares <gm...@chromium.org<javascript:>> wrote:

On Fri, Apr 19, 2013 at 12:15 PM, Brandon Jones <baj...@google.com<javascript:>> wrote:
Many mobile games use vibration for player feedback, and I'm not aware of any phones with more than one motor, so this would be appropriate for that case.

Agreed. It's just that you'll need a new API for 2 motors and yet another API for multiple controllers.


It does feel odd to call this out as a gaming-targeted API though, and suggesting this is associated with gamepad vibration is probably misleading.

On Fri, Apr 19, 2013 at 11:06 AM, Gregg Tavares <gm...@chromium.org<javascript:>> wrote:
I have to ask, the spec says

"The API is designed to tackle use cases related to gaming, and is not meant to be used as a generic notification mechanism."

And yet the API exposed doesn't seem to relate to games. Current and last gen controllers have multiple motors with weights of different sizes. Spinning those 2 weights at different frequencies relative to each other is what produces the tactile feedback players are used to

Will this end up being a deprecated API once support for gaming vibration is added?

On Fri, Apr 19, 2013 at 9:41 AM, Michael van Ouwerkerk <mvanou...@google.com<javascript:>> wrote:
Emails

Michael van Ouwerkerk (mvanou...@chromium.org<javascript:>)
Miguel Garcia (TL) (mig...@chromium.org<javascript:>)

[Jon Rimmer]

On Friday, April 19, 2013 5:41:39 PM UTC+1, Michael van Ouwerkerk wrote:

Apple has expressed some concerns, but did not provide much detail: https://lists.webkit.org/pipermail/webkit-dev/2012-January/019283.html

I can't speak for Simon Fraser / Apple, but his objection chimes somewhat with my own concern that many of Mozilla's device and sysapps APIs are unimaginative 1:1 translations of phone features, driven mainly by the requirements of FirefoxOS.

I'd rather see web APIs that generalise an intent, and provide some leeway to user agents as to how that intent is expressed, than these very specific representations of device capabilities and input methods. I worry that the approach typified by the vibration API will lead to content that is designed expressly for a particular set of device capabilities, and is inaccessible anywhere they are not available, resulting in fragmentation of the web.

Jon

[Eric Seidel]

The spec link is actually:

http://www.w3.org/TR/vibration/

It's CR and there is only one compatible implementation, so I believe this qualifies under guidelines #2 and #3:

http://www.chromium.org/blink#compatibility

I think this is useful technology to have in the browser, and so I agree we should implement this.

LGTM to implement.

Given how simple this feature is I don't think it necessitates a runtime flag, although I would prefer that all features use one if possible. :)  I'm OK with it being implemented un-guarded at this time, and thus:

LGTM to ship (you still need 2 more).

[Dimitri Glazkov]

Another LGTM.

:DG<

[Ojan Vafai]

On Tue, Apr 23, 2013 at 2:08 PM, Eric Seidel <ese...@chromium.org> wrote:

The spec link is actually:

http://www.w3.org/TR/vibration/

The original link was correct. We want to review the latest version of the draft, which is the editor's draft. It's just a quirk of the W3C process that the editor's draft is not labelled as a Candidate Recommentation. A quirk that we should ignore IMO. There's been many a centithread on getting rid of TR specs at the W3C. Doesn't seem like it's going to happen anytime soon unfortunately.

It's CR and there is only one compatible implementation, so I believe this qualifies under guidelines #2 and #3:

http://www.chromium.org/blink#compatibility

I think this is useful technology to have in the browser, and so I agree we should implement this.

LGTM to implement.

Given how simple this feature is I don't think it necessitates a runtime flag, although I would prefer that all features use one if possible. :)  I'm OK with it being implemented un-guarded at this time, and thus:

LGTM to ship (you still need 2 more).

LGTM as well.