[whatwg] Device proximity and light events

[Jonas Sicking]

On Tue, May 8, 2012 at 12:33 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Tue, May 8, 2012 at 9:12 PM, Andrei Popescu <andreip at google.com> wrote:
>> Neither have we and we have been supporting device orientation for a
>> while in both Chrome (desktop and Android) and Android Web Browser...
>> To me, Doug's proposal seems reasonable.
>
> Is the expectation that these new events, similar to orientation, fire
> on an interval of some kind? Describing this in terms of adding and
> removing event listeners does not seem wise as at some point somebody
> might start using that for things that do not fire pretty much all the
> time feeling justified by these proposals.
>
> The problem with that, as explained before, is that the event model assumes that
>
>  addEventListener(...)
>  // nothing happens for a while
>  addEventListener(...)
>
> will not cause it to be dispatched twice. Defining these features as
> events that fire regularly however does not have the same problem.

I think that is how we would semantically define it.

The fact that we can turn off the sensor as soon as all event
listeners for the event are removed is effectively an implementation
detail. But likely an implementation detail that's worth pointing out
in the spec so that web pages can take advantage of it and remove
event listeners when they want to save battery.

The reason that I'm not really happy with this API is the fact that it
forces pages to remove all event listeners in order to shut down a
sensor. It seems more author friendly to me to allow pages to keep
event listeners registered but to have an "on/off" switch which they
can use to control if they want the sensor to be enabled. (Setting it
to "off" would of course only affect if events are delivered to that
page. If another page set it to "on" the UA would still fire the
events to the second page, and that page only).

Technically we could add such a switch later if the switch's default
value is "on".

/ Jonas