Re: [sensors] the near/far event names

I requested that we have this be optional since Firefox has already shipped without this attribute.


I am pretty sure that this attribute is going to be troublesome and it is one of those things we can bike shed all day on.   Hence, i think we should just punt and look at this issue after we have something wildly deployed and have reported problems with the API. 

However, if we do want to continue with this attribute, I think that we need to have normalized language around this def. or interopt is not going to happen.

Doug



----- Original Message -----
From: "Jonas Sicking" <jonas@sicking.cc>
To: "Marcos Caceres" <marcosscaceres@gmail.com>
Cc: public-device-apis@w3.org
Sent: Sunday, May 13, 2012 1:43:23 AM
Subject: Re: [sensors] the near/far event names

On Fri, May 11, 2012 at 10:26 AM, Marcos Caceres
<marcosscaceres@gmail.com> wrote:
> What about going with what Robin suggested:
>
> window.addEventListener("proximity", function(e){});
>
> And the Event:
>
> e.min ...
> e.max ...
> e.value ...
> e.proximity = "far" || "near" ?

Given that the by far most common use-case is likely to be to want
adjust application behavior based on near/far, I think it would be a
good design if we had an event just for that. This would prevent
getting lots of events all telling the author that the device is still
"near" the user's face. That will also minimize the risk of website
breakage if we ever transition to higher resolution sensors since the
near/far event wouldn't change at all.

But I would also be ok with simply keeping it simple and just sticking
the new property on the existing event. Though I don't think the event
should be optional since I don't see a reason why implementations
couldn't do a best-approximation implementation.

/ Jonas

Received on Sunday, 13 May 2012 20:47:25 UTC