Re: [Vibration] Feedback on the Vibration API

Hi David,

On 13.11.2012, at 17.55, ext David Bruant wrote:

> Hi,
> 
> I'd like to get back to the point about step 5 (and step 3 too in a way). I've written a script (or rather a hack) that enables getting the maximum vibration value https://gist.github.com/4066406

Nice script :-)

> What I'm trying to show here is that apps developers can get the info with the current API if they really want. I feel it would be somewhat cleaner to have the implementation exposing the value to avoid hacks (and potentially weird UX at app startup if that's when you run this hack).

Developers can always try abuse APIs, but that may be shortsighted. Clever implementation might suppress the vibrations coming from such script and add the origin to a blacklist (see "pages at a given origin should never be able to vibrate the device"). Somewhat similarly to how the overuse of alerts()s is blocked by most modern implementations.

The spec is intentionally not exposing this information. By doing this, the spec steers web developers in not discriminating against user agents which may support smaller vibration time, or no vibration at all, than what the developer might request. My device may be set to silent, vibration may be turned off as a user's preference, or to save battery, but I still want to play that game!

In other words, we want to prevent code such as:

if (vibrateMax < 10000) alert('Sorry, your device is not supported!');

This is a bit analogous to the way how some web sites may discriminate against user agents that employ a smaller resolution screen.

By not providing this information, we gently nudge developers in designing their apps in such a way that they don't expect certain maximum vibration time, or rely on vibration support to be there at all.

Btw. I still haven't seen a real world use case where this would be a real issue, and continue to encourage you to experiment with the implementations out there already to find that out.

> Also, I have a another piece of feedback. In the 10th step the vibration occur. I feel it should be expressed in some way that these steps are performed asynchronously (that's what triggered my first question in my initial post), because it really looks like they're performed synchronously.

The specs are written mostly to implementors (that is, browser vendors), so the language may be a bit unfamiliar to other groups of people (it shouldn't necessarily be that way, and we're open to suggestions how to make the specs more understandable to other groups!). In this case, the key is the referenced "spin the event loop" concept (and the whole Event Loops section):

  http://dev.w3.org/html5/spec/webappapis.html#spin-the-event-loop

Web specs use references extensively so they don't need to define the same concepts again.

Thanks for your cool script and comments!

-Anssi

Received on Wednesday, 14 November 2012 17:16:18 UTC