Edit comment LC-2900 for Device and Sensors Working Group

Quick access to LC-2900

Comment LC-2900

Comment Shortname:

Commenter:

On Behalf Of:

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeVibration API W3C Last Call Working Draft 11 February 201... Vibration API W3C Last Call Working Draft 11 February 2014... Vibration API W3C Last Call Working Draft 11 February 2014 Abstract This specification defines an API that provides ac... Abstract Status of This Document This section describes the status o... Status of This Document 5 February 2004 W3C Patent Policy Table of Contents 1. Introduction 2. Conformance 3. Termin... Table of Contents 1. Introduction 2. Conformance 3. Terminology 4. Vibration... 1. Introduction This section is non-normative. The API is s... 1. Introduction 2. Conformance As well as sections marked as non-normative,... 2. Conformance user agent 3. Terminology The concepts browsing context and spin the e... 3. Terminology browsing context spin the event loop 4. Vibration Interface partial interface Navigator { b... 4. Vibration Interface partial interface Navigator { boolean vibrate ((unsigned... vibrate() processing vibration patterns Note Note Note 5. Examples This section is non-normative. In the following... 5. Examples A. Acknowledgements The group is deeply indebted to Justin... A. Acknowledgements B. References B.1 Normative references [HTML5] Robin Berj... B. References B.1 Normative references [HTML5] Robin Berjon; Steve Faulk... B.1 Normative references [HTML5] [PAGE-VISIBILITY] [RFC2119] [WEBIDL] B.2 Informative references [notifications] John Gregg; Ann... B.2 Informative references [notifications]
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody Bah, Slimane Bernhart, Bryan Bhaumik, Rijubrata Bogdanovich, Ilya Caceres, Marcos Christiansen, Kenneth DADAS, Mohammed Gouaillard, Alexandre Grant, Reilly Hazaël-Massieux, Dominique Hirsch, Frederick Hu, Ningxin huang, qigang Hwang, Dongseong Jeon, Jonathan Kang, Shin-Gak Kim, Sung Hei Kim, Sunghan Kinlan, Paul Kis, Zoltan Kliche, Ingmar Kollarova, Martina Kostiainen, Anssi Krishnan, Sanjay Lamouri, Mounir Lee, Dong-Young Lee, Kangchan Lee, Seungyun Lee, WonSuk Lin, Wanming Liu, Dapeng Liu, Guanyu Logvinov, Andrey Mandyam, Giridhar McCathie Nevile, Charles Mehrnezhad, Maryam Mikityuk, Alexandra Nilsson, Claes Olejnik, Lukasz Pashidis, Michallis Poussa, Sakari Pozdnyakov, Mikhail Raggett, Dave Scheib, Vincent Shalamov, Alexander Song, Jungkee Spreitzer, Raphael Steglich, Stephan Stojiljkovic, Aleksandar Tran, Dzung Waldron, Rick Walsh, Michael WEI, XIAOHAI xiong, aiden Xue, Fuqiao Yamamoto, Eiji Yamazaki, Fumi Zhang, Rong Zhang, Zhiqiang zhong, heng

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

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.

Related issues: (space separated ids)

WG Notes: additional note on extensions, http://lists.w3.org/Archives/Public/public-device-apis/2014Feb/0037.html

Resolution: No change, use library to provide convenience interface, http://lists.w3.org/Archives/Public/public-device-apis/2014Feb/0033.html

(Please make sure the resolution is adapted for public consumption)

Check to confirm deletion (not reversible)