RE: Next step for DAP Ambient Light Events

I agree, this is déjà vu.

+1 to leaving the current API as-is and providing another as needed for the simpler use cases, or providing some way through the API to map lux ranges to the enumerated set of values, e.g. provide the lux value plus what the implementation thinks it maps to. Would that allow setting a value change listener on each, for the different use cases?

Thanks,
Bryan Sullivan 

> -----Original Message-----
> From: Tran, Dzung D [mailto:dzung.d.tran@intel.com]
> Sent: Monday, September 10, 2012 9:20 PM
> To: Doug Turner; Tab Atkins Jr.
> Cc: François REMY; Marcos Caceres; Doug Turner; CSS WG; public-device-
> apis@w3.org
> Subject: RE: Next step for DAP Ambient Light Events
> 
> I am in favor of the below.
> Thanks
> 
> 
> -----Original Message-----
> From: Doug Turner [mailto:doug.turner@gmail.com]
> Sent: Monday, September 10, 2012 2:49 PM
> To: Tab Atkins Jr.
> Cc: François REMY; Marcos Caceres; Doug Turner; CSS WG; public-device-
> apis@w3.org
> Subject: Re: Next step for DAP Ambient Light Events
> 
> > For my own needs, yes.  The range names are more than sufficient for
> > page/app styling based on light conditions.  You should only need to
> > use the lux value if you're doing a game or something that wants a
> > continuous value.
> 
> Exactly.  That is why we expose the lux value.  Removing the value means
> reducing the use cases.
> 
> For what its worth, this conversation is similar to the discussion the
> DAP had regarding proximity events.  Proximity sensors  report how far
> an object is away from a sensor.  This is reported by the
> DeviceProximityEvent.  However, we felt there was a need for a very
> specific event that reported if the 'user' was near or far from the
> sensor.  The use case is basically if the users's face is close to the
> sensor or not.  For this, the UserProximityEvent was invented.
> 
> Maybe we should leave DeviceAmbientLight alone and add a new event type
> for reporting changes in the general range of ambient lighting.
> 
> Thoughts?
>

Received on Tuesday, 11 September 2012 17:24:32 UTC