DAP-ISSUE-155: Enable Feature Detection [Vibration API]

DAP-ISSUE-155: Enable Feature Detection [Vibration API]

http://www.w3.org/2009/dap/track/issues/155

Raised by: Glenn Adams
On product: Vibration API

On behalf of Michael van Ouwerkerk

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?

Received on Thursday, 10 October 2013 00:18:01 UTC