[admin proximity] Re: Proximity Events Feedback

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 UTC