W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2012

[admin proximity] Re: Proximity Events Feedback

From: <Frederick.Hirsch@nokia.com>
Date: Fri, 7 Dec 2012 19:17:56 +0000
To: <annevk@annevk.nl>
CC: <Frederick.Hirsch@nokia.com>, <public-device-apis@w3.org>
Message-ID: <1CB2E0B458B211478C85E11A404A2B2701853AA3@008-AM1MPN1-033.mgdnok.nokia.com>
I have added a Last Call Comment Tracker instance to track this issue, LC-2731, (and noted Anssi's response) - https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-proximity-20121206/2731

regards, Frederick

Frederick Hirsch, Nokia
Chair, W3C DAP Working Group



On Dec 7, 2012, at 5:39 AM, ext Anne van Kesteren wrote:

> 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,
> 
> 
> -- 
> http://annevankesteren.nl/
> 
Received on Friday, 7 December 2012 19:18:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 December 2012 19:18:34 GMT