Re: [Vibration API] Confusing list indexing in spec

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
vibration."

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.

-Justin

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