Re: [ambient light] Updated ED as per LC comments

Anssi

Thanks for the updates, comments inline

regards, Frederick

Frederick Hirsch
Nokia



On Jan 10, 2013, at 8:08 AM, ext Anssi Kostiainen wrote:

> Hi,
> 
> I volunteered to help Doug with Ambient Light Events spec edits. To start with, I updated the Editor's Draft [ED] as per my actions. I also found one untracked LC comment that was addressed too.
> 
> Below is an overview of changes and links to details:
> 
> * ACTION-605: Update Ambient Light specification for [LC-2737], bringing queueing order update from Proximity to Ambient Light
> 
> - address Anne's Proximity LC feedback, applies to Ambient Light Events too <http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0016.html>:
> 
>  https://dvcs.w3.org/hg/dap/rev/d3a2ee4266a8
> 
> - define enum LightLevelState:
> 
>  https://dvcs.w3.org/hg/dap/rev/51296676e203
> 
> [I note that the formatting of enum may not be optimal, changing that requires changes to ReSpec.]
> 
> - remove RFC terms from notes <http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0016.html>:
> 
>  https://dvcs.w3.org/hg/dap/rev/685f81b473d3
> 
> * ACTION-606: Update Proximity and Ambient Light to define events, per [LC-2738]
> 
> - define default values for the event interface members <http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0055.html>
> 
>  https://dvcs.w3.org/hg/dap/rev/2f675457d430
> 
> * ACTION-607: Update Ambient Light per [LC-2737], bringing any questions to the list
> 
> All except the following is addressed by ACTION-605:
> 
> [[
> 
> If your device is not doing anything, e.g. completely stationary,
> these sensors would theoretically not change and you would never be
> able to get the actual state. That might be a mostly academic problem,
> but this seems like another set of events that violate the spirit of
> DOM Events. Kinda ambivalent on whether that's good or bad, but I
> think it at least ought to be pointed out more clearly. And perhaps we
> ought to define this more explicitly by having some kind of hook in
> addEventListener?
> 
> ]]
> 
> Any suggestions how to address the above concern?

Simple approach might be firing event when the constructor is instantiated - ie. first change is from unknown state to known state.

"When the current light changes or the interface is first instantiated, the user agent must fire a device light event."

> 
> I also addressed the following feedback that was not explicitly tracked:
> 
> - address Tab's editorial comments re intros, notes <http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0050.html>:
> 
>  https://dvcs.w3.org/hg/dap/rev/1c5fc74bd529

I thought I'd entered Tab's comment into tracker, now I have, thanks for noting it. LC-2741: https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-ambient-light-20121213/2741 


> 
> All - please review the changes, and let us know if you have any concerns or further feedback.
> 
> -Anssi
> 
> [ED] http://dvcs.w3.org/hg/dap/raw-file/tip/light/Overview.html
> 
> [LC-2737] https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-ambient-light-20121213/2737
> 
> [LC-2738] https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-ambient-light-20121213/2738

Received on Thursday, 10 January 2013 15:01:26 UTC