Proximity Events Feedback

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 10:40:10 UTC