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

Re: addEventListener and side effects (was: CfC to change Sensor approach, not progress current draft)

From: Doug Turner <dougt@mozilla.com>
Date: Thu, 22 Mar 2012 09:49:08 -0700
Cc: Robin Berjon <robin@berjon.com>, Frederick.Hirsch@nokia.com, public-device-apis@w3.org
Message-Id: <DB741CA7-F86E-4222-8C84-B52876953FE0@mozilla.com>
To: Dominique Hazael-Massieux <dom@w3.org>

On Mar 22, 2012, at 9:43 AM, Dominique Hazael-Massieux wrote:

> Le jeudi 22 mars 2012 à 09:36 -0700, Doug Turner a écrit :
>> On Mar 22, 2012, at 9:32 AM, Dominique Hazael-Massieux wrote:
>>> Le jeudi 22 mars 2012 à 09:24 -0700, Doug Turner a écrit :
>>>> I am taking a much simpler approach to this whole thing.  Here is what
>>>> I am doing for proximity.  It follows what we did for device motion:
>>>>   https://dougturner.wordpress.com/2012/03/22/device-proximity/
>>> It's simpler, but not that much simpler. One reason I took the approach
>>> I mentioned is that some proximity sensors only report a boolean state
>>> (near/far); without a notion of accuracy, I don't know how your proposal
>>> addresses this.
>> yes, but it is simpler and follows a known pattern. 
> So does my proposal (it's modeled on the battery API).

The battery API isn't shipping everywhere.  Device orientation (and soon device motion) is shipping in Firefox, Opera, and Chrome.  

> (if in fact activation-on-addEventListener is OK, I'll update
> http://scriptlib-cg.github.com/api-design-cookbook/ to reflect this)

Sure.  It is what Device Motion and Orientation is doing.  Why would it now be bad for other APIs to do this?  Lets strive for consistency.
Received on Thursday, 22 March 2012 16:49:41 UTC

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