Re: [vibra] Vibration API -- the first stab (was: Mozilla's WebVibrator contribution)

On Fri, Oct 28, 2011 at 5:02 AM, Anssi Kostiainen
<anssi.kostiainen@nokia.com> wrote:
> On 28.10.2011, at 12.32, ext Dominique Hazael-Massieux wrote:
>
>> Le jeudi 27 octobre 2011 à 18:38 +0300, Anssi Kostiainen a écrit :
>>> Here's the first draft of the Vibration API spec as promised:
>>>  http://dev.w3.org/2009/dap/vibration/
>>
>> Thanks for getting this started!
>>
>>> It's basically Mozilla's implementation, with the following changes and some clarifications:
>>> * vibrate() is exposed on navigator.vibration instead of navigator
>>
>> navigator.vibration.vibrate seems a bit redundant; but I guess that's as
>> good a strawman as any other proposal :)
>
> Yes, it's a placeholder, and not the best one especially if we want to supplement the interface in the future with other tactile feedback mechanisms.
>
> I'd suggest we mentally say s/vibration/foo/ so that we do not invest too much energy into naming discussions -- yet :)

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.

>>> * 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.

>>> * 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.

/ Jonas

Received on Monday, 31 October 2011 16:16:27 UTC