- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 19 Jun 2012 11:21:18 +0200
- To: Justin Lebar <justin.lebar@gmail.com>
- Cc: Anssi Kostiainen <anssi.kostiainen@nokia.com>, public-device-apis@w3.org
Hi Justin, On Jun 18, 2012, at 15:40 , Justin Lebar wrote: > A few more nits, if you don't mind, plus some important points at the end: > > * "This document represents the consensus of the group on the scope > and features of the Vibration API. It should be noted that the group > is aware of more advanced use cases that cannot be realised using this > simpler first version. The intent is to address them in a future > revision." > > This is repeated; does it need to appear twice? No, that was a bug that showed up in a release of ReSpec (the tool that makes the spec look like one) that duplicated the infamous "custom SotD paragraph". It was fixed a few days ago, but the script might still be in your cache. > And the material points: > > * "9. An implementation may abort the algorithm at this point." > > This occurs after step 3: "If pattern is 0, or an empty list, cancel > the pre-existing instance of the processing vibration patterns > algorithm, if any, and abort these steps." But if a page can't > vibrate the device, the page also shouldn't be able to cancel other > page's vibrations. > > The reason that step 9 appears where it does is because we want pages > which can't vibrate the page not to be able to observe this fact. So > error checking on the args has to appear before we abort the > algorithm. I suggest rejiggering the algorithm order so that we do > all the error checking upfront, then give the UA a chance to abort, > then either cancel or start a vibration. Agreed, and good catch. Proposed order: 2, 4, 5, 6, 7, 1 + 9 (merged into a single step), 8, 3 (without cancellation, just abort), 10. > * "If the device does not provide a vibration mechanism, or it is > disabled, the user agent must silently ignore any invocations of the > vibrate() method." Seems to me that we should still do the error > checking from the vibration algorithm, but then behave as though no > page has permission to frob the vibrator. Yes, I think that this should be moved into the algorithm, as part the step labelled "3" in the above rejig. "If pattern is 0 or an empty list, or if the device does not provide a vibration mechanism (or it is disabled) abort these steps." > * "When the visibilitychange event [PAGE-VISIBILITY] is dispatched at > the Document, the user agent must run the following steps: [either > suppress or restore the vibration]". > > A few problems here. First, this only applies if the currently > running instance of the vibration algorithm was started by this > document. > > Second, it's not clear in the spec what it means to "suppress" or > "restore" the vibration. > > Third, my implementation in Firefox simply cancels the vibration when > the page becomes invisible. If that matches what other > implementations do, we should consider changing the spec to match. I agree that restoring vibration complicates matters and adds little value (developers who really insist on this can listen to visibilitychange). -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 19 June 2012 09:21:46 UTC