- From: Michael van Ouwerkerk <mvanouwerkerk@google.com>
- Date: Thu, 9 Oct 2014 15:18:16 +0100
- 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>
- Message-ID: <CAF40kP5Gjgqt8rV_GHdeDE7Ox2=cZb9qy8gmngvJN_p7YFicbA@mail.gmail.com>
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:53 UTC