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.kostiai...@intel.com> wrote: > [+public-device-api] > > On 09 Oct 2014, at 15:46, Anne van Kesteren <ann...@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 >
