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

Re: Vibration API: making feature detection possible

From: Michael van Ouwerkerk <mvanouwerkerk@chromium.org>
Date: Wed, 9 Oct 2013 14:05:04 +0100
Message-ID: <CAF40kP7A9aXd2aPH9MWqmP5Jvz9SGO_Zp0gpQafgqF=sWEZRiw@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:01 UTC