W3C home > Mailing lists > Public > public-device-status@w3.org > November 2011

Re: [vibra] Vibration API -- the first stab

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Tue, 1 Nov 2011 14:58:53 -0700
Cc: ext Dominique Hazael-Massieux <dom@w3.org>, "public-device-apis@w3.org WG" <public-device-apis@w3.org>, <public-device-status@w3.org>
Message-Id: <91B236A8-43DE-43D7-A950-58491713366A@nokia.com>
To: ext Jonas Sicking <jonas@sicking.cc>
On 31.10.2011, at 9.15, ext Jonas Sicking wrote:

> I personally prefer to skip the middle man here and just go with
> navigator.vibrate(). The only harm that I can see in having a lot of
> API directly on navigator would be if we end up with name collisions,
> but I don't think there's a big risk of that. Long names is something
> which people continuously complain about.

I agree developer ergonomics is better without the middle man. I changed the spec accordingly.

>>>> * two event handlers added: onvibrationstart and onvibrationend
>>> What are the use cases for these events?
>> This comes from a game developer:
>>  https://bugzilla.mozilla.org/show_bug.cgi?id=679966#c25
>> Paul Bakaus doesn't mention any use cases, but I could see how having a one-to-many dependency between the vibration and other objects could be useful. For example, lets say there are N angry trolls on the screen, and each of the trolls acts differently when the device vibrates. Being able to notify N objects automatically seems useful.
> As you mention, that link doesn't contain any use cases. I don't think
> we should add these events until we have such use cases.
> I do agree that if we should have a callback for when the vibrator is
> turned on, it should be DOM-Event based as to allow multiple
> listeners. However until we have such use cases, I don't think we add
> any callbacks at all.
> It sounds strange to me to have elements of the game act differently
> when the device vibrates given that the device vibrating is in direct
> control of the page. It would be like having elements of the game act
> differently depending on what the background color of the app is.
> It seems more likely that the game would call a function which turns
> on the vibrator and then makes all the trolls fall over.

I dropped the handlers for now. Lets consider adding them back if people come up with high value use cases for them.

>>>> * the exceptions raised by vibrate() are 'SyntaxError' and 'NotSupportedError'
>>> I think the SyntaxError exception is not needed, since Web IDL gives use
>>> TypeError for free in these cases.
>> That'd be great. How would you describe that in WebIDL exactly? Mozilla's implementation states:
> I think something like the following would work:
> partial interface Navigator {
>  void vibrate(long[] pattern);
>  void vibrate(long time);
> }
> The first signature would be number of milliseconds on, number of
> milliseconds off, etc. The second signature would simply be number of
> milliseconds on.
> Any call to either of these functions would first cancel any already
> existing vibration. Hence vibrate(0) or vibrate([]) would both cancel
> any existing vibrations.

Updated the IDL and the 'processing vibration patterns' algorithm accordingly:


Thanks again for the feedback!

Received on Tuesday, 1 November 2011 21:59:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:42:59 UTC