Single page view
In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.
In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.
| Commentor | Comment | Working Group decision | Commentor reply |
|---|
LC-2900
Iain Dawson <iain@musicfortheblind.co.uk> (archived comment) |
I really don't like that the Vibration API assigns meaning to the numbers
in lists handed to it based solely on the oddness of their indices. This
means developers have to be incredibly careful to only ever extend their
lists two items at a time or risk subtle, difficult-to-track-down bugs.
One solution would be to create lists of lists of [activeTime, restTime],
but even this creates a situation where future extensions of the API would
have to run on top of a completely different interface.
>From my perspective, the *right* way to do this, while a little more
verbose, would be much more extensible and much more explicit; have the
thing take a list of vibration objects formatted something like {time:
[number], vibrate: [bool]}. This means you don't have to keep track of the
index of every item you append to your list and you open the door to future
parameters such as intensity or, who knows, motor selection in hypothetical
multi-vibration-motor devices.
It would, of course, be possible to support all three of these interfaces,
if so desired.
|
No change, use library to provide convenience interface, http://lists.w3.org/Archives/Public/public-device-apis/2014Feb/0033.html |
yes |
|---|