Re: Proximity Events Feedback

Hi Anne,

On 7.12.2012, at 12.39, ext Anne van Kesteren wrote:

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

Fixed in the ED.

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

Are you referring to the ReSpec-generated boilerplate or something else?

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

Applied s/may/can/g to the problematic note.

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

We could augment the existing note to make this clearer. Do you have a preference or a suggestion what we should say about this? 

> And perhaps we ought to define this more explicitly by having some kind of hook in addEventListener?

A hook might help as this is likely to become an issue with other specs too. I guess DeviceOrientationEvent was the first one to use this pattern, and there are other similar specs (e.g. Ambient Light Events) in the pipeline.

The Editor's Draft:

  http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html

Changes as per your feedback:

  http://dvcs.w3.org/hg/dap/rev/4c339a6b4be4

Thanks for the review!

-Anssi

Received on Friday, 7 December 2012 14:14:47 UTC