W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2014

Re: Vibration

From: Michael van Ouwerkerk <mvanouwerkerk@google.com>
Date: Thu, 9 Oct 2014 15:18:16 +0100
Message-ID: <CAF40kP5Gjgqt8rV_GHdeDE7Ox2=cZb9qy8gmngvJN_p7YFicbA@mail.gmail.com>
To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Mounir Lamouri <mounir@lamouri.fr>, www-archive <www-archive@w3.org>, Device APIs Working Group <public-device-apis@w3.org>
Currently the min and max values of vibrations and pauses are not defined,
and not exposed either. Same for max length of a pattern. I can imagine
users running into these limits and never knowing that the call did not
have the intended result.

/m


On Thu, Oct 9, 2014 at 2:32 PM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> [+public-device-api]
>
> On 09 Oct 2014, at 15:46, Anne van Kesteren <annevk@annevk.nl> wrote:
>
> > Is there anything in http://dev.w3.org/2009/dap/vibration/ you would
> > have done differently today in terms of the API? We want to add
> > vibration support to the notifications API as part of a general set of
> > behaviors, see https://github.com/whatwg/notifications/issues/22 Was
> > just wondering if the API should be the same or slightly different. In
> > particular overloading long with a sequence of long does not seem
> > great.
>
> We tried to keep the scope as tight as possible and did not add any
> extras, thus not much to do differently.
>
> The overloading aspect of the API was there from the start. This is
> something we inherited from the early Mozilla experimental implementations
> and managed to stood the test of time. Some pretty cool projects were built
> atop this API, so the design seems to work fine from the web author’s
> perspective at least.
>
> Some people questioned whether there should be means to detect the
> existence or the actual vibration motor. We settled on a design that the
> API behaves identically regardless of whether the hosting device has an
> actual vibration motor or not. This is to allow implementers to use
> alternative means to emulate vibration (sounds, shake screen, electric
> shock, whatnot the future brings) in devices that do not have the
> supporting hardware. Secondly, we’re not leaking any information that could
> be used for fingerprinting.
>
> Someone also proposed strength/intensity feature, but since it was
> demonstrated one can emulate intensity with the existing API using pulse
> modulation methods pretty easily, we did not see great rush to spec that.
> Also hardware support for strength was/is limited.
>
> The current API ships in both desktop and mobile browsers [1], and we have
> a test suite [2].
>
> Thanks,
>
> -Anssi
>
> [1] http://caniuse.com/#feat=vibration
> [2] http://w3c.github.io/test-results/vibration/all.html
>
Received on Thursday, 9 October 2014 14:18:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC