Re: [whatwg] Device proximity and light events

2012-07-11 Thread Ian Hickson
On Fri, 4 May 2012, Doug Turner wrote:

 I have added two new events to Firefox which allow web apps to detect 
 light and proximity changes.
 
 http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/ 
 http://dougturner.wordpress.com/2012/03/26/device-light-sensor/

I spoke to Doug about this on IRC and for now I'm not going to spec this 
in the HTML spec. It would probably be good for these events to be 
combined with the Geo and device orientation events and all specced 
together, but I'll leave that up to whoever specs them. :-)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


Re: [whatwg] Device proximity and light events

2012-07-11 Thread Doug Turner
Hey Ian,

The Sensor API Specification in the W3 is going to own them.

- Original Message -
From: Ian Hickson i...@hixie.ch
To: wha...@whatwg.org
Sent: Wednesday, July 11, 2012 3:27:17 PM
Subject: Re: [whatwg] Device proximity and light events

On Fri, 4 May 2012, Doug Turner wrote:

 I have added two new events to Firefox which allow web apps to detect 
 light and proximity changes.
 
 http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/ 
 http://dougturner.wordpress.com/2012/03/26/device-light-sensor/

I spoke to Doug about this on IRC and for now I'm not going to spec this 
in the HTML spec. It would probably be good for these events to be 
combined with the Geo and device orientation events and all specced 
together, but I'll leave that up to whoever specs them. :-)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


Re: [whatwg] Device proximity and light events

2012-05-09 Thread Anne van Kesteren
On Wed, May 9, 2012 at 5:59 AM, Doug Turner do...@mozilla.com wrote:
 Where was that discussion?

This came up at the WebApps F2F and there was general agreement that
if we added new events adding new event handler attributes would make
sense. Feature detection of some kind is useful as forcing people to
do UA sniffing leads to badness.


-- 
Anne — Opera Software
http://annevankesteren.nl/
http://www.opera.com/


Re: [whatwg] Device proximity and light events

2012-05-09 Thread Rich Tibbett

Scott González wrote:

On Tuesday, May 8, 2012, Doug Turner wrote:


You don't.  This API doesn't have device detection.  Don't assume that
onXXX means that the UA supports an event.



I thought this was the preferred way to check. I seem to recall a
discussion about this and agreement that this was the best way to detect
events.


The WHATWG spec [1] itself says the following:

When support for a feature is disabled (e.g. as an emergency measure to 
mitigate a security problem, or to aid in development, or for 
performance reasons), user agents must act as if they had no support for 
the feature whatsoever, and as if the feature was not mentioned in this 
specification. For example, if a particular feature is accessed via an 
attribute in a Web IDL interface, the attribute itself would be omitted 
from the objects that implement that interface — leaving the attribute 
on the object but making it return null or throw an exception is 
insufficient.


If the feature is not yet implemented then the same principle should 
apply IMO (if that's not implicit in the above).


- Rich

[1] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#extensibility


Re: [whatwg] Device proximity and light events

2012-05-09 Thread Doug Turner

On May 9, 2012, at 3:14 AM, Anne van Kesteren wrote:

 On Wed, May 9, 2012 at 5:59 AM, Doug Turner do...@mozilla.com wrote:
 Where was that discussion?
 
 This came up at the WebApps F2F and there was general agreement that
 if we added new events adding new event handler attributes would make
 sense.

Was there any notes taken?


 Feature detection of some kind is useful as forcing people to
 do UA sniffing leads to badness.

I am not arguing that it shouldn't be done.   I just don't think it as 
important as most people.  For example, even if the device is present, it may 
be off or not responding.  In that case, you'll have a feature that tests 
positive and never receive any events.

Re: [whatwg] Device proximity and light events

2012-05-09 Thread Scott González
There was a related discussion on the mailing list:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-November/029252.html

I also found a message from Hixie to me, related to that thread: I agree
entirely that if an event has a use case, it makes sense for it to have an
event handler attribute.


On Wed, May 9, 2012 at 10:31 AM, Doug Turner do...@mozilla.com wrote:


 On May 9, 2012, at 3:14 AM, Anne van Kesteren wrote:

  On Wed, May 9, 2012 at 5:59 AM, Doug Turner do...@mozilla.com wrote:
  Where was that discussion?
 
  This came up at the WebApps F2F and there was general agreement that
  if we added new events adding new event handler attributes would make
  sense.

 Was there any notes taken?


  Feature detection of some kind is useful as forcing people to
  do UA sniffing leads to badness.

 I am not arguing that it shouldn't be done.   I just don't think it as
 important as most people.  For example, even if the device is present, it
 may be off or not responding.  In that case, you'll have a feature that
 tests positive and never receive any events.


Re: [whatwg] Device proximity and light events

2012-05-09 Thread Tran, Dzung D
There is a discussion on the DAP WG, we like the simplicity of the proposal 
however there is an important feature that is missing which is ability to set 
the report interval and threshold.

Thanks
Dzung Tran

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Doug Turner
Sent: Wednesday, May 09, 2012 7:31 AM
To: Anne van Kesteren
Cc: Jonas Sicking; wha...@whatwg.org; Scott González; JOSE MANUEL CANTERA 
FONSECA; Andrei Popescu; Carr, Wayne
Subject: Re: [whatwg] Device proximity and light events


On May 9, 2012, at 3:14 AM, Anne van Kesteren wrote:

 On Wed, May 9, 2012 at 5:59 AM, Doug Turner do...@mozilla.com wrote:
 Where was that discussion?
 
 This came up at the WebApps F2F and there was general agreement that
 if we added new events adding new event handler attributes would make
 sense.

Was there any notes taken?


 Feature detection of some kind is useful as forcing people to
 do UA sniffing leads to badness.

I am not arguing that it shouldn't be done.   I just don't think it as 
important as most people.  For example, even if the device is present, it may 
be off or not responding.  In that case, you'll have a feature that tests 
positive and never receive any events.


Re: [whatwg] Device proximity and light events

2012-05-09 Thread Doug Turner
That is different -- Hixie can chime in.

I think the idea is that if you have and dom event handler, you should also 
have an on event handler attribute.  Its meaning is less defined.  I do not 
think it means that if ondevicemotion exists, that means you will always see 
device motion events.

Doug


On May 9, 2012, at 7:45 AM, Scott González wrote:

 There was a related discussion on the mailing list: 
 http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-November/029252.html
 
 I also found a message from Hixie to me, related to that thread: I agree 
 entirely that if an event has a use case, it makes sense for it to have an 
 event handler attribute.
 
 
 On Wed, May 9, 2012 at 10:31 AM, Doug Turner do...@mozilla.com wrote:
 
 On May 9, 2012, at 3:14 AM, Anne van Kesteren wrote:
 
  On Wed, May 9, 2012 at 5:59 AM, Doug Turner do...@mozilla.com wrote:
  Where was that discussion?
 
  This came up at the WebApps F2F and there was general agreement that
  if we added new events adding new event handler attributes would make
  sense.
 
 Was there any notes taken?
 
 
  Feature detection of some kind is useful as forcing people to
  do UA sniffing leads to badness.
 
 I am not arguing that it shouldn't be done.   I just don't think it as 
 important as most people.  For example, even if the device is present, it may 
 be off or not responding.  In that case, you'll have a feature that tests 
 positive and never receive any events.
 



Re: [whatwg] Device proximity and light events

2012-05-09 Thread Scott González
The original question was How do you detect if the UA supports each of
these sensor?

I don't think we're asking whether you'd get events, but whether you can
detect that the UA actually supports the event. I would think the UA should
expose support (via onxxx attributes) if the UA and device actually have
support, even if the sensor is turned off. There may be a separate API for
determining if the sensor is turned on, but I don't think that's what was
being asked.


On Wed, May 9, 2012 at 10:48 AM, Doug Turner do...@mozilla.com wrote:

 That is different -- Hixie can chime in.

 I think the idea is that if you have and dom event handler, you should
 also have an on event handler attribute.  Its meaning is less defined.
  I do not think it means that if ondevicemotion exists, that means you will
 always see device motion events.

 Doug


 On May 9, 2012, at 7:45 AM, Scott González wrote:

  There was a related discussion on the mailing list:
 http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-November/029252.html
 
  I also found a message from Hixie to me, related to that thread: I
 agree entirely that if an event has a use case, it makes sense for it to
 have an event handler attribute.
 
 
  On Wed, May 9, 2012 at 10:31 AM, Doug Turner do...@mozilla.com wrote:
 
  On May 9, 2012, at 3:14 AM, Anne van Kesteren wrote:
 
   On Wed, May 9, 2012 at 5:59 AM, Doug Turner do...@mozilla.com wrote:
   Where was that discussion?
  
   This came up at the WebApps F2F and there was general agreement that
   if we added new events adding new event handler attributes would make
   sense.
 
  Was there any notes taken?
 
 
   Feature detection of some kind is useful as forcing people to
   do UA sniffing leads to badness.
 
  I am not arguing that it shouldn't be done.   I just don't think it as
 important as most people.  For example, even if the device is present, it
 may be off or not responding.  In that case, you'll have a feature that
 tests positive and never receive any events.
 




Re: [whatwg] Device proximity and light events

2012-05-08 Thread Andrei Popescu
On Fri, May 4, 2012 at 10:38 PM, Doug Turner do...@mozilla.com wrote:
 Right, but they haven't been a real problem in practice.


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.

Thanks,
Andrei


 Doug

 On May 4, 2012, at 2:32 PM, JOSE MANUEL CANTERA FONSECA wrote:

 but you have the same issue as with motion and orientation which is that you 
 cannot control the watch parameters for the sensor and the side effects of 
 addEventListener
 
 De: whatwg-boun...@lists.whatwg.org [whatwg-boun...@lists.whatwg.org] En 
 nombre de Doug Turner [do...@mozilla.com]
 Enviado el: viernes, 04 de mayo de 2012 22:03
 Para: Tran, Dzung D
 CC: wha...@whatwg.org
 Asunto: Re: [whatwg] Device proximity and light events

 I looked at the Sensor API.  I was hoping to have something very simple and 
 lightweight.  I most likely will implement other sensor types in the same 
 way - simple dom events with attributes that are specific to the event.  
 This is what we did for device motion and orientation, and it has worked out 
 quite well.

 Thanks!
 Doug




 On May 4, 2012, at 11:34 AM, Tran, Dzung D wrote:

 Hello Doug,

 Proximity and Light is currently in the Sensor API spec at:

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

 This spec is in process of revising. I am planning to update this in the 
 next couple of days.

 Thanks
 Tran


 -Original Message-
 From: whatwg-boun...@lists.whatwg.org 
 [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Doug Turner
 Sent: Friday, May 04, 2012 11:02 AM
 To: wha...@whatwg.org
 Subject: [whatwg] Device proximity and light events

 I have added two new events to Firefox which allow web apps to detect light 
 and proximity changes.

 http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/
 http://dougturner.wordpress.com/2012/03/26/device-light-sensor/

 I'd like feedback and to see if there was any interest in supporting these 
 events in other UAs.

 Thanks
 Doug



 Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
 nuestra política de envío y recepción de correo electrónico en el enlace 
 situado más abajo.
 This message is intended exclusively for its addressee. We only send and 
 receive email on the basis of the terms set out at
 http://www.tid.es/ES/PAGINAS/disclaimer.aspx



Re: [whatwg] Device proximity and light events

2012-05-08 Thread Anne van Kesteren
On Tue, May 8, 2012 at 9:12 PM, Andrei Popescu andr...@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.


-- 
Anne — Opera Software
http://annevankesteren.nl/


Re: [whatwg] Device proximity and light events

2012-05-08 Thread Jonas Sicking
On Tue, May 8, 2012 at 12:33 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Tue, May 8, 2012 at 9:12 PM, Andrei Popescu andr...@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


Re: [whatwg] Device proximity and light events

2012-05-08 Thread Doug Turner

On May 8, 2012, at 3:26 PM, Jonas Sicking wrote:

 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.

True.  I haven't heard of anyone actually worrying about this. 

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

I do not think we have similar on/off switch APIs for other DOM apis…. Do we?

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

Yup, if there is a demand for it, it is easy to add such a feature.  I want to 
keep these APIs as damn simple as possible.

Doug




Re: [whatwg] Device proximity and light events

2012-05-08 Thread Jonas Sicking
On Tue, May 8, 2012 at 3:33 PM, Doug Turner do...@mozilla.com wrote:

 On May 8, 2012, at 3:26 PM, Jonas Sicking wrote:

 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.

 True.  I haven't heard of anyone actually worrying about this.

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

 I do not think we have similar on/off switch APIs for other DOM apis…. Do we?

We haven't really had any other pieces of hardware which a page could
want to switch on/off so I'm not sure the question really applies.

/ Jonas


Re: [whatwg] Device proximity and light events

2012-05-08 Thread Carr, Wayne
How do you detect if the UA supports each of these sensor?

I thought when I first looked at this there was on on the window object for 
one of them but not the other.  But I don't see it for either. 


-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-
boun...@lists.whatwg.org] On Behalf Of Jonas Sicking
Sent: Tuesday, May 08, 2012 4:02 PM
To: Doug Turner
Cc: JOSE MANUEL CANTERA FONSECA; wha...@whatwg.org; Andrei Popescu
Subject: Re: [whatwg] Device proximity and light events

On Tue, May 8, 2012 at 3:33 PM, Doug Turner do...@mozilla.com wrote:

 On May 8, 2012, at 3:26 PM, Jonas Sicking wrote:

 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.

 True.  I haven't heard of anyone actually worrying about this.

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

 I do not think we have similar on/off switch APIs for other DOM apis…. Do we?

We haven't really had any other pieces of hardware which a page could want to
switch on/off so I'm not sure the question really applies.

/ Jonas


Re: [whatwg] Device proximity and light events

2012-05-08 Thread Doug Turner
You don't.  This API doesn't have device detection.  Don't assume that onXXX 
means that the UA supports an event.


On May 8, 2012, at 6:34 PM, Carr, Wayne wrote:

 How do you detect if the UA supports each of these sensor?
 
 I thought when I first looked at this there was on on the window object 
 for one of them but not the other.  But I don't see it for either. 
 
 
 -Original Message-
 From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-
 boun...@lists.whatwg.org] On Behalf Of Jonas Sicking
 Sent: Tuesday, May 08, 2012 4:02 PM
 To: Doug Turner
 Cc: JOSE MANUEL CANTERA FONSECA; wha...@whatwg.org; Andrei Popescu
 Subject: Re: [whatwg] Device proximity and light events
 
 On Tue, May 8, 2012 at 3:33 PM, Doug Turner do...@mozilla.com wrote:
 
 On May 8, 2012, at 3:26 PM, Jonas Sicking wrote:
 
 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.
 
 True.  I haven't heard of anyone actually worrying about this.
 
 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).
 
 I do not think we have similar on/off switch APIs for other DOM apis…. Do 
 we?
 
 We haven't really had any other pieces of hardware which a page could want to
 switch on/off so I'm not sure the question really applies.
 
 / Jonas



Re: [whatwg] Device proximity and light events

2012-05-08 Thread Scott González
On Tuesday, May 8, 2012, Doug Turner wrote:

 You don't.  This API doesn't have device detection.  Don't assume that
 onXXX means that the UA supports an event.


I thought this was the preferred way to check. I seem to recall a
discussion about this and agreement that this was the best way to detect
events.


Re: [whatwg] Device proximity and light events

2012-05-08 Thread Doug Turner

On May 8, 2012, at 7:23 PM, Scott González wrote:

 On Tuesday, May 8, 2012, Doug Turner wrote:
 You don't.  This API doesn't have device detection.  Don't assume that onXXX 
 means that the UA supports an event.
 
 I thought this was the preferred way to check. I seem to recall a discussion 
 about this and agreement that this was the best way to detect events. 


Where was that discussion?

Re: [whatwg] Device proximity and light events

2012-05-04 Thread Tran, Dzung D
Hello Doug,

Proximity and Light is currently in the Sensor API spec at: 

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

This spec is in process of revising. I am planning to update this in the next 
couple of days.

Thanks
Tran


-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Doug Turner
Sent: Friday, May 04, 2012 11:02 AM
To: wha...@whatwg.org
Subject: [whatwg] Device proximity and light events

I have added two new events to Firefox which allow web apps to detect light and 
proximity changes. 

http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/
http://dougturner.wordpress.com/2012/03/26/device-light-sensor/

I'd like feedback and to see if there was any interest in supporting these 
events in other UAs.

Thanks
Doug



Re: [whatwg] Device proximity and light events

2012-05-04 Thread Doug Turner
I looked at the Sensor API.  I was hoping to have something very simple and 
lightweight.  I most likely will implement other sensor types in the same way - 
simple dom events with attributes that are specific to the event.  This is what 
we did for device motion and orientation, and it has worked out quite well.

Thanks!
Doug




On May 4, 2012, at 11:34 AM, Tran, Dzung D wrote:

 Hello Doug,
 
 Proximity and Light is currently in the Sensor API spec at: 
 
 http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html
 
 This spec is in process of revising. I am planning to update this in the next 
 couple of days.
 
 Thanks
 Tran
 
 
 -Original Message-
 From: whatwg-boun...@lists.whatwg.org 
 [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Doug Turner
 Sent: Friday, May 04, 2012 11:02 AM
 To: wha...@whatwg.org
 Subject: [whatwg] Device proximity and light events
 
 I have added two new events to Firefox which allow web apps to detect light 
 and proximity changes. 
 
 http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/
 http://dougturner.wordpress.com/2012/03/26/device-light-sensor/
 
 I'd like feedback and to see if there was any interest in supporting these 
 events in other UAs.
 
 Thanks
 Doug
 



Re: [whatwg] Device proximity and light events

2012-05-04 Thread JOSE MANUEL CANTERA FONSECA
but you have the same issue as with motion and orientation which is that you 
cannot control the watch parameters for the sensor and the side effects of 
addEventListener

De: whatwg-boun...@lists.whatwg.org [whatwg-boun...@lists.whatwg.org] En nombre 
de Doug Turner [do...@mozilla.com]
Enviado el: viernes, 04 de mayo de 2012 22:03
Para: Tran, Dzung D
CC: wha...@whatwg.org
Asunto: Re: [whatwg] Device proximity and light events

I looked at the Sensor API.  I was hoping to have something very simple and 
lightweight.  I most likely will implement other sensor types in the same way - 
simple dom events with attributes that are specific to the event.  This is what 
we did for device motion and orientation, and it has worked out quite well.

Thanks!
Doug




On May 4, 2012, at 11:34 AM, Tran, Dzung D wrote:

 Hello Doug,

 Proximity and Light is currently in the Sensor API spec at:

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

 This spec is in process of revising. I am planning to update this in the next 
 couple of days.

 Thanks
 Tran


 -Original Message-
 From: whatwg-boun...@lists.whatwg.org 
 [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Doug Turner
 Sent: Friday, May 04, 2012 11:02 AM
 To: wha...@whatwg.org
 Subject: [whatwg] Device proximity and light events

 I have added two new events to Firefox which allow web apps to detect light 
 and proximity changes.

 http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/
 http://dougturner.wordpress.com/2012/03/26/device-light-sensor/

 I'd like feedback and to see if there was any interest in supporting these 
 events in other UAs.

 Thanks
 Doug



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx


Re: [whatwg] Device proximity and light events

2012-05-04 Thread Doug Turner
Right, but they haven't been a real problem in practice.

Doug

On May 4, 2012, at 2:32 PM, JOSE MANUEL CANTERA FONSECA wrote:

 but you have the same issue as with motion and orientation which is that you 
 cannot control the watch parameters for the sensor and the side effects of 
 addEventListener
 
 De: whatwg-boun...@lists.whatwg.org [whatwg-boun...@lists.whatwg.org] En 
 nombre de Doug Turner [do...@mozilla.com]
 Enviado el: viernes, 04 de mayo de 2012 22:03
 Para: Tran, Dzung D
 CC: wha...@whatwg.org
 Asunto: Re: [whatwg] Device proximity and light events
 
 I looked at the Sensor API.  I was hoping to have something very simple and 
 lightweight.  I most likely will implement other sensor types in the same way 
 - simple dom events with attributes that are specific to the event.  This is 
 what we did for device motion and orientation, and it has worked out quite 
 well.
 
 Thanks!
 Doug
 
 
 
 
 On May 4, 2012, at 11:34 AM, Tran, Dzung D wrote:
 
 Hello Doug,
 
 Proximity and Light is currently in the Sensor API spec at:
 
 http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html
 
 This spec is in process of revising. I am planning to update this in the 
 next couple of days.
 
 Thanks
 Tran
 
 
 -Original Message-
 From: whatwg-boun...@lists.whatwg.org 
 [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Doug Turner
 Sent: Friday, May 04, 2012 11:02 AM
 To: wha...@whatwg.org
 Subject: [whatwg] Device proximity and light events
 
 I have added two new events to Firefox which allow web apps to detect light 
 and proximity changes.
 
 http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/
 http://dougturner.wordpress.com/2012/03/26/device-light-sensor/
 
 I'd like feedback and to see if there was any interest in supporting these 
 events in other UAs.
 
 Thanks
 Doug
 
 
 
 Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
 nuestra política de envío y recepción de correo electrónico en el enlace 
 situado más abajo.
 This message is intended exclusively for its addressee. We only send and 
 receive email on the basis of the terms set out at
 http://www.tid.es/ES/PAGINAS/disclaimer.aspx