Re: [Vibration API] Confusing list indexing in spec

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