Re: [Vibration] Feedback on the Vibration API

Hi David,

On 6.11.2012, at 12.21, ext David Bruant wrote:

> Le 06/11/2012 10:35, Anssi Kostiainen a écrit :

>> The expectation is that implementations set the limit to a reasonable level and do that for a good reason. E.g. sometimes the user may not want the device to vibrate at all, but does not want the web app to know that due to privacy reasons.
>> 
>> I don't think we have a high value use cases for vibrating for a very long time outside of adult industry, so in most cases you should not hit the limit anyway.

> It's not that much about "a very long time", but any time at all since the spec provides no insight as to which value is acceptable.
> You wrote "the expectation" and "reasonable level". I wish this was documented in the spec with numbers of what is considered to be "reasonable". Because right now, an implementation can do almost anything and is considered valid.

That is to say this is intentionally left as an implementation detail. It is also a quality of implementation issue.

The spec is intentionally written in such a way that even if your device would not have a vibrator actuator hardware, the existing code depending on this API would continue to work.  In that particular case good quality implementations might use some alternative means to let the user know the web app is trying to vibrate (e.g. shake the screen, play a buzzing sound, show an indicator ...). As a real life example, AFAIK, Firefox ships with this API enabled on all platforms, yet only some of the supported platforms have hardware support for the feature.

> It doesn't make it easy for developers to write apps that will last. If I write an app that vibrates for 800ms and that works fine with current phones, what guarantees that in the next year, a new phone won't arrive to the market with a 750ms limitation? Why not a legislation that prevents new phone from vibrating more than 700ms in a row? It would break applications.
> Also, should I read the hardware spec of every new hardware to make sure my app won't crash? Should I test on every phone to make sure it works well?
> 
> I don't have use cases, but I worry a lot about the longevity of code and the current API does not really provide a lot of information that will help applications to properly work in new complying environments.

We certainly worry about the longevity of code. We worry about the longevity of specifications too. If we set a reasonable limit today, that may not make sense for future implementations. Keep the API surface as small as possible is one of the best practices of API design. You can always add things later, but you can’t take them away.

I encourage you to write code against the existing implementations out there to see if the limit is an issue, and file bugs against implementations if needed. In Firefox, you can configure the limit via about:config > dom.vibrator.max_vibrate_ms.

> The point about the OS not exposing this kind of information is compelling, but that should be the only reason not to expose reasons to throw in my opinion.

I think there are other valid reasons too, as outlined above.

Thanks for your comments!

-Anssi

Received on Tuesday, 6 November 2012 12:40:18 UTC