W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2012

Re: [Vibration API] Confusing list indexing in spec

From: Justin Lebar <justin.lebar@gmail.com>
Date: Wed, 20 Jun 2012 09:57:38 -0400
Message-ID: <CAFWcpZ4cGt3kkt_ksg2_NsuOJ19Ab6j29w9U0Z9-43PcXW_=Mw@mail.gmail.com>
To: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Cc: ext Robin Berjon <robin@berjon.com>, public-device-apis@w3.org
This look a lot better!  Some more nits:

* "6. If the hidden attribute [PAGE-VISIBILITY] is set to true, abort
these steps. An implementation may abort the algorithm at this point."

It seems to me that this is actually two steps.

* "When the visibilitychange event [PAGE-VISIBILITY] is dispatched at
the Document in a browsing context, the user agent must cancel the

This still isn't particularly precise.  As I read it, whenever any
document gets a visibilitychange event, we must cancel...something.
It's not "the pre-existing instance of the processing vibration
patterns algorithm, if any", like in step 7.


On Wed, Jun 20, 2012 at 7:02 AM, Anssi Kostiainen
<anssi.kostiainen@nokia.com> wrote:
> Hi Robin, All,
> On 19.6.2012, at 12.21, ext Robin Berjon wrote:
>> On Jun 18, 2012, at 15:40 , Justin Lebar wrote:
> [...]
>>> 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.
> I reordered the algorithm as outlined above. Please check if it looks okay.
>>> * "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."
> I moved that into the algorithm.
>>> * "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).
> I think simplifying this makes a lot of sense, especially given that for more advanced use cases there's the fallback you mentioned. I reworked that part of the spec as I outlined in my reply to Justin.
> Thanks for the feedback!
> -Anssi
Received on Wednesday, 20 June 2012 13:58:30 UTC

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