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

Re: [vibration] Preliminary thoughts on the vibrator spec

From: Justin Lebar <jlebar@mozilla.com>
Date: Fri, 11 Nov 2011 16:16:53 -0500
Message-ID: <CAFWcpZ6E_f8+g2zD4Y6pPQ4XfWW6Q+CMG6zERoBOpRDmYL_ZEw@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Anssi Kostiainen <anssi.kostiainen@nokia.com>, public-device-apis@w3.org, public-device-status@w3.org
> An implementation should be allowed to disable vibration in any way if it wants to for security or privacy reasons.

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

This is still too restrictive.  An implementation may also disable
vibration just because the user asked.  Also, I don't know what it
means to disable vibration "in any way."

How about we add a step to the algorithm, between steps 8 and 9:

"9) An implementation may abort the algorithm at this point.

"Non-normative note: For example, an implementation might abort the
algorithm because the user has set a preference indicating that pages
at a given origin should never be able to vibrate the page, or an
implementation might cap the total amount of time a page may cause the
device to vibrate and reject requests in excess of this limit."

On Thu, Nov 10, 2011 at 12:18 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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 Friday, 11 November 2011 21:17:46 UTC

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