W3C

Disposition of comments for the Device APIs Working Group

paged 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.

CommentorCommentWorking Group decisionCommentor reply
LC-2731 Anne van Kesteren <annevk@annevk.nl> (archived comment)
Hi,

I would kindly suggest you reorder the requirement for queueing with
the requirement for firing. E.g. "The user agent must queue a task to
fire a device proximity event." (and then remove the requirement for
queueing from the firing steps). This matches phraseology in other
specifications better and allows for reuse of the firing definition in
other contexts.

You defined "ondeviceproximity" and "onuserproximity" twice. This
seems to be because of the legacy-DOM-style formatting.

Do not use RFC 2119 terms in notes, such as "may".

If your device is not doing anything, e.g. completely stationary,
these sensors would theoretically not change and you would never be
able to get the actual state. That might be a mostly academic problem,
but this seems like another set of events that violate the spirit of
DOM Events. Kinda ambivalent on whether that's good or bad, but I
think it at least ought to be pointed out more clearly. And perhaps we
ought to define this more explicitly by having some kind of hook in
addEventListener?

Kind regards,
done, see https://dvcs.w3.org/hg/dap/diff/4c339a6b4be4/proximity/Overview.html

reply sent to Anne: http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0021.html
tocheck
LC-2742 Anne van Kesteren <annevk@annevk.nl> (archived comment)
I just noticed your specification has the same issue as the Ambient
thingie. You're not defining default values for the event interface
members. (new UserProximityEvent("haha")).near is undefined. I suggest
adding that to the testsuite. (It's one of the basic things to cover
when testing event constructors.)
https://dvcs.w3.org/hg/dap/rev/52acb4877e86

reply sent to Anne: http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0021.html
tocheck
LC-2740 Rick Waldron <waldron.rick@gmail.com> (archived comment)
On Fri, Dec 7, 2012 at 5:39 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

>
> If your device is not doing anything, e.g. completely stationary,
> these sensors would theoretically not change and you would never be
> able to get the actual state. That might be a mostly academic problem,
> but this seems like another set of events that violate the spirit of
> DOM Events. Kinda ambivalent on whether that's good or bad, but I
> think it at least ought to be pointed out more clearly. And perhaps we
> ought to define this more explicitly by having some kind of hook in
> addEventListener?
>


I've been thinking about this since the last call yesterday as well.

Early in my development of the Johnny-Five framework, I decided that all
sensors must:

1. Generate events

- sensor.on("change", .... ); // Any change to the reading value(s)
- sensor.on("read", .... ); // Every sensor reading

2. Allow value read accessors

- sensor.value; // sensors w/ a single value
- sensor.axis.{ x, y, z } // multiple values (ie. accelerometer, as
shown here)

3. Stream (in progress)

- http://maxogden.com/node-streams.html


But of course, this design is meant to facilitate an arbitrary number of
sensors, eg. you might have an array of 4 proximity or sonar sensors on a
robot to aid in navigation. This level of scalability may not
seem practical for mobile devices, but then I'm reminded of
navigator.getUserMedia that was originally spec'ed with no thought about
multiple cameras—implementations then have to figure it out.


I understand there is platform precedence to consider, ie. DeviceMotion and
DeviceOrientation APIs and this nicely matches, but If I was asked to
start from scratch, I'd start with a Proximity (or
DeviceProximity...something similar) constructor that initialized proximity
objects that had properties: max, min and value and could dispatch events
by inheriting EventTarget. I have no expectation that the current system
would be changed like this, so consider this entirely "just for fun". :)


Rick
The DeviceProximityEvent constructor takes an optional DeviceProxmityEventInit dictionary that includes min, max and value.

The WG has decided to keep the current design which reflects earlier decisions since it is not 'starting from scratch'.

The WG also has decided to keep the Ambient Light Events and Proximity Events specifications separate to allow independent conformance and testing, although they share commonality.
yes
LC-2732 Rick Waldron <waldron.rick@gmail.com> (archived comment)
I see the distance measurement unit "in centimeters" is mentioned only
once, in the description of "current device proximity", I would suggest
being explicit and including it in "minimum proximity distance" and
"maximum proximity distance" as well.

Rick
http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0014.html

fixed this in the latest Editor's Draft: http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html

Diff: http://dvcs.w3.org/hg/dap/rev/c877e2c764b5
yes

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: doc.php,v 1.36 2014-02-19 08:10:56 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org