Re: Proximity Events Feedback

[+cc Doug, Marcos]

Hi Anne,

On 18.12.2012, at 14.40, ext Anne van Kesteren wrote:

> On Fri, Dec 7, 2012 at 3:14 PM, Anssi Kostiainen
> <anssi.kostiainen@nokia.com> wrote:
>> On 7.12.2012, at 12.39, ext Anne van Kesteren wrote:
>>> 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?
> 
> I think so. http://wiki.whatwg.org/wiki/Howto_spec#Legacy_DOM-style
> explains some of the problems.

If I understood you correctly this could be fixed by removing all "Attributes" and "Dictionary XXX Members" sections (and updating the TOC accordingly). I'll need to dive into ReSpec and see if I could craft a patch to make this a config flag. I could quickly monkey patch this but that'd be a bit hackish, I guess.

>>> 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?
> 
> The current note does not seem at all clear about how this will
> actually be implemented. Explaining that would be more interesting I
> think than handwaving the issue.

Doug - given you've implemented this feature, what do you think we should say in the note to address Anne's concern? This is what the note says currently:

[[

The definition of granularity i.e. how often the event is fired is left to the implementation. Implementations can fire the event if they have reason to believe that the page does not have sufficiently fresh data. Different devices can also support different minimum and maximum sensing distances as well as different resolution, thus authors are strongly advised to use theUserProximityEvent interface if they are only interested in finding out if the user is near or far.

]]

> I just noticed your specification has the same issue as the Ambient
> thingie.

The Ambient Light Events spec is a fork of the Proximity Events spec so it inherits its initial issues. I should perhaps update the Ambient thingie too.

Doug - do you mind if I start patching the Ambient Light Events spec too?

> You're not defining default values for the event interface
> members. (new UserProximityEvent("haha")).near is undefined.

I updated the spec as follows:

  http://dvcs.w3.org/hg/dap/rev/52acb4877e86

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

> I suggest adding that to the testsuite. (It's one of the basic things
> to cover when testing event constructors.)

Sure.

Marcos - we're not testing this currently, right?

-Anssi

Received on Thursday, 20 December 2012 09:53:38 UTC