- From: Michael van Ouwerkerk <mvanouwerkerk@chromium.org>
- Date: Wed, 9 Oct 2013 14:05:04 +0100
- To: "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>
- Cc: Michael van Ouwerkerk <mvanouwerkerk@chromium.org>, "<public-device-apis@w3.org>" <public-device-apis@w3.org>
- Message-ID: <CAF40kP7A9aXd2aPH9MWqmP5Jvz9SGO_Zp0gpQafgqF=sWEZRiw@mail.gmail.com>
It's quite a generic API, so the fallback could be a number of things. Enhanced visual or audio feedback perhaps. Regards, Michael On Tue, Oct 8, 2013 at 8:20 PM, <Frederick.Hirsch@nokia.com> wrote: > I believe one reason for not doing this is to reduce the possibility of > fingerprinting through feature detection. > > Is there a strong reason to need to know whether or not vibration is > enabled, when asking for vibration with the expectation for best effort may > be good enough? > > What is the use case for the change? If vibration is not possible what > would be reasonable fallbacks (flash the screen a la emacs)? > > regards, Frederick > > Frederick Hirsch > Nokia > > > > On Oct 8, 2013, at 12:34 PM, ext Michael van Ouwerkerk wrote: > > Hi, I'm currently working on implementing the Vibration API in Blink and > Chromium, and I'd like to propose making feature detection possible. > > In its current form, the Vibration API exposes the navigator.vibrate > method. When you call it with valid arguments, it returns true. However, > this only indicates that the arguments were valid. It does not mean any > vibrations have been scheduled. Nothing might happen, perhaps because there > is no hardware for it. Do all phones have such hardware? How about tablets, > or laptops? Or, perhaps there is no permission for vibrating right now. > > To give web developers an opportunity to provide a fallback for their > users, I think it should be possible to detect when they will not be able > to vibrate the device. > > The simplest approach might appear to just not expose navigator.vibrate > when vibration is not available. However, this would require that the > browser detect availability of vibration in the startup path. It might be > an asynchronous process as well. This is a problem for implementation in > the browser. > > My proposal is that we make use of Promises, so that the setup is > asynchronous, and it is clear how to handle failure. > > In JavaScript, it would look something like this: > window.navigator.getVibrator().then(function(vibrator) { > vibrator.vibrate([100, 0, 50]); > }, function() { > // No vibrator is available. Provide fallback or exit. > }); > > What do you think? > > Regards, > > Michael van Ouwerkerk > > >
Received on Wednesday, 9 October 2013 13:05:32 UTC