Re: [vibration] Preliminary thoughts on the vibrator spec

On 10.11.2011, at 19.18, ext Jonas Sicking wrote:

> On Thu, Nov 10, 2011 at 4:10 AM, Anssi Kostiainen
> <> wrote:
>> The arguments are type of 'unsigned long' and 'unsigned long[]'. According to Web IDL (
>> * 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.

According to Web IDL ( if an array is expected but null is passed a TypeError is thrown (ToObject(null) throws TypeError as per ECMA-262).

I'm wondering if the easiest solution would indeed be to drop null from the following processing step as per Jonas' original proposal:


* If pattern is 0, an empty list, or null, cancel the pre-existing instance of the processing vibration patterns algorithm, if any, and abort these steps.


Anyone having objections against dropping null?


Received on Monday, 14 November 2011 13:31:42 UTC