- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Thu, 16 Jun 2011 15:50:43 +0300
- To: ext Doug Turner <doug.turner@gmail.com>
- CC: <public-device-apis@w3.org>
Hi Doug, On 15.6.2011, at 19.48, ext Doug Turner wrote: > There are a few concerns/ideas I have about the Battery API. > > 1) I do not think we want handlers to hang off of the window object. > > window.onbatterystatus is bad. we have addEventHandler() I notice the Device Orientation Event only exposes itself via window.addEventListener(), while e.g. the online and offline events also have document.ononline and document.onoffline handlers (mirrored also on document.body) as well as corresponding attributes on the <body>. But there's nothing on window. So perhaps window.onbatterystatus should not be there in the global namespace. How do others feel about that? > 2) I'd like two new events -- BatteryLow and BatteryCriticallyLow. > Other than people implementing battery widgets, I am not sure that > |battery.level| means anything -- not all batteries are created equal, > they have different decay rates, and I am not sure we want web > developers having to calculate when the battery is actually "low". With my web developer hat on I'd love the idea of being able to rely on the implementations providing me reliable and consistent (with each other) BatteryLow and BatteryCriticallyLow events. That said, I also see that a clever JavaScript hacker could come up with a Battery.js library built on top of the current event that would provide me such functionality (by monitoring the level over time). > 3) We can factor out |battery.plugged| into a new separate event that > can fire when there is a change in state. People may want just this > information and not the |battery.level|. Is there an (implementation) cost of getting the level as well at the same time? Thanks for your helpful comments! -Anssi
Received on Thursday, 16 June 2011 12:48:25 UTC