Re: [vibration] Preliminary thoughts on the vibrator spec

On Thu, Nov 10, 2011 at 4:10 AM, Anssi Kostiainen
<anssi.kostiainen@nokia.com> wrote:
> Hi Jonas,
>
> On 10.11.2011, at 1.18, ext Jonas Sicking wrote:
>
>> On Wed, Nov 9, 2011 at 11:39 AM, Justin Lebar <jlebar@mozilla.com> wrote:
>>>>> Algorithm step 5: "If pattern is 0, an empty list," **null, or undefined**
>>>>
>>>> There was earlier discussion that including null and undefined may not make sense so they were
>>>> dropped:
>>>>
>>>> http://lists.w3.org/Archives/Public/public-device-status/2011Oct/0048.html
>>>>
>>>> I added null and undefined back for now, this should be a minor issue anyway.
>>>
>>> I don't think it's quite as bad as the following looks:
>>>
>>>> vibrate(undefined)
>>>> vibrate()
>>>> vibrate(null)
>>>> vibrate(0)
>>>> vibrate([])
>>>
>>> The last two obviously have to be there.  But then any one of the
>>> first three implies the other two.  In particular, I think |vibrate()|
>>> is less clunky than vibrate(0) or vibrate([]).
>>
>> I think it's surprising that vibrate() would turn off the vibrator.
>>
>>> Jonas, do you still think we should get rid of the first three above?
>>> I guess I don't feel strongly either way.
>>
>> Yeah, I see no reason for them to make it into the spec, and no reason
>> for us to diverge from the spec.
>
> The arguments are type of 'unsigned long' and 'unsigned long[]'. According to Web IDL (http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long):
>
> * negative values throw a TypeError
>
> * undefined throws a TypeError (ToNumber(undefined) === NaN as per ECMA-262, and NaN throws TypeError as per Web IDL)
>
> * null is converted to 0 (ToNumber(null) === +0 as per ECMA-262), and thus vibrate(null) should behave similarly to vibrate(0)
>
> Given this, I dropped undefined, but kept null. So all these will cancel the operation similarly:
>
> vibrate(null)
> vibrate(0)
> vibrate([])
>
> Does this sound reasonable?

Is this the case even when there are overloads? In that case type
coercion happens much more rarely since we don't know what type to
coerce to.

>>> If you're going to spec it this way, you should specify what it means
>>> to pause the algorithm while a vibration is playing -- presumably you
>>> mean that we should cancel the current vibration and resume however
>>> many ms are left when the page becomes visible again.
>>
>> ...I guess that's what you are arguing for here?
>>
>>>> If the device does not provide a vibration mechanism, or it is disabled, the user agent must silently
>>>> ignore any invocations of the vibrate() method.
>>>
>>> Maybe we should have a non-normative section saying that the UA may
>>> allow the user to disable vibration globally, per-origin, or however
>>> else it wants.
>>
>> I think it needs to be a normative section, since otherwise it doesn't
>> change the normative requirements. But yeah, I think we should simply
>> say that an implementation should be allowed to disable vibration in
>> any way if it wants to for security or privacy reasons.
>
> Added the following normative prose as per your proposal:
>
> [[
>
> An implementation should be allowed to disable vibration in any way if it wants to for security or privacy reasons.
>
> ]]

I think "is" would be more correct than "should be".

/ Jonas

Received on Thursday, 10 November 2011 17:25:56 UTC