Hello Andres, The Battery Status API is deliverable of the Device APIs Working Group, so I'm copying the group's list public-device-a...@w3.org.
(keeping public-webapps in BCC FYI) Dom Le dimanche 05 juin 2011 à 22:44 -0700, Andres Riofrio a écrit : > I have some comments on the Battery Status API. > > I was wondering why it was that the battery status API is exposed > using Events (and adding an additional requirement "When an event > listener is registered with the event type batterystatus, then the > User Agent must dispatch a BatteryStatusEvent event immediately."), > when the Geolocation API is exposed using a getCurrent and a watch > function, that invoke a callback when the information is available. Is > there a rationale for using a different paradigm than the (kind of) > established Geolocation API? I think it'd be better (saner for > developers) to use the same paradigm. > > Further, doesn't the requirement that a BatteryStatusEvent be > dispatched immediately incur a synchronous delay as the browser gets > that information? That is, nothing else can happen because the event > must be dispatched immediately. I might understand wrongly, but if > this is the case, I think it should be changed to "retrieves the > relevant information and dispatches a BatteryStatusEvent > asynchronously". > > Andres Riofrio > > >