W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2016

Re: [vibration] Returning false if vibration hardware is not present?

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Wed, 20 Jan 2016 09:55:02 +0000
To: Philip Rogers <pdr@chromium.org>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <A9AF3F3C-A100-4949-B321-8EB1B91A8FBD@intel.com>
Hi Philip,

> On 19 Jan 2016, at 22:11, Philip Rogers <pdr@chromium.org> wrote:
> 
> The vibration api is currently spec'd to return false from vibrate(...) if the page is not visible or (optionally) if the user has disabled vibration. Can the spec be amended to return false if vibration hardware is not present too?

Thanks for your feedback.

Actually, the following step allows an implementation to return false also if the hardware is not present:

[[ 

An implementation MAY return false and terminate these steps. [1]

]]

The conditions under which false may be returned are intentionally left unspecified -- it would be impossible to enumerate all the possible reasons in the spec, thus the use of somewhat uncommon "MAY". Examples given in the note that follows the step are just informative, and not a complete list.

> Some mobile devices such as the Nexus 7 do not have hardware support for vibration. I'd like to provide feedback to users when their hardware doesn't support vibration. There is an Android API for accessing this: Vibration.hasVibrator(), though I couldn't find an API on iOS.

The catch with the current API is, you cannot detect the reason for failure, but I believe your use case does not require that. Knowing that the device did not vibrate when vibrate() was invoked is enough?

> Ideally we would return a promise but that change is probably not web compatible. Another option is to add something like hasVibrator(). Because false is already returned for a variety of cases where vibration is not possible, I think it makes sense to also return false when hardware support prevents vibration.

For the background, a similar issue was raised in 2013 [2]. At that time the group decided to not add such a feature to the Vibration API, but was open to consider future APIs with this in mind. For example, the Battery Status API was gated behind a promise for similar reasons. I attempted to summarize the thread at [3].

If we today have a strong use case for explicit feature detection, wider support from browser vendors, no fingerprinting or accessibility worries, and we're able to expose this new feature in a web compatible way, I believe we could start "Vibration API Level 2" spec and bake such a feature into it. Since this is a new feature, it does not qualify as an errata update for the existing spec that has reached Recommendation aka final stage.

Thanks,

-Anssi

[1] https://www.w3.org/TR/vibration/#dfn-perform-vibration
[2] https://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0074.html
[3] https://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0135.html
Received on Wednesday, 20 January 2016 09:55:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC