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

Re: Proximity Events Feedback

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Fri, 7 Dec 2012 16:14:04 +0200
Cc: <public-device-apis@w3.org>
Message-Id: <538A3816-3A6D-4F3D-B94A-138B9A641ED1@nokia.com>
To: ext Anne van Kesteren <annevk@annevk.nl>
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:


Changes as per your feedback:


Thanks for the review!

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:47 UTC