W3C home > Mailing lists > Public > public-device-apis@w3.org > August 2011

[battery] addEventListener side effects, ordering & boundary crossing of battery{low, critical}, window.on*

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Thu, 18 Aug 2011 14:54:29 +0300
Message-ID: <23D6BB2B-2E52-4DB3-960F-A6D245E497F3@nokia.com>
To: "public-device-apis@w3.org WG" <public-device-apis@w3.org>

Here's a list of remaining Battery Status Events -related issue and actions, and proposed resolutions for each. Look for this diff for changes made to the spec:


* ISSUE-113: AddEventListener in Battery Status has side effects

The discussion on public-geolocation on the same issue was inconclusive:


It seems there's a tradeoff between consistency, performance, ease of use (for developers), and architectural purity with any of the available alternatives. The current design is arguably fairly consistent, shouldn't have performance pitfalls, and should be easy for developers. Thus I'd propose to leave it as is in the spirit of:


(If we would simply remove the requirement "When an event listener is registered with the event type batterystatus, then the user agent must ..." e.g. a battery monitor use case could not be implemented consistently. You'd get the status only after isPlugged changes its value or level changes by 1%. In the worst case, where the isPlugged is true and the battery is at 100%, you would not get *any* battery status information until the device is unplugged. To alleviate that the level threshold could be changed, but that'd compromise the performance.

* ISSUE-114: Battery spec should note relative ordering of battery low versus battery critical in terms of criticality

I've added prose to make this clearer.

* ISSUE-115: Do you get the batterylow event when you're charging and cross that boundary?

As discussed, firing less events is better for (battery) performance, thus I propose the batterylow and batterycritical events are only fired if the battery is depleting while crossing the boundaries.

I've added prose for that.

(In some implementations even if the device is plugged in the battery could deplete under heavy load. The proposed design leaves it to the implementation to figure out if the events should be fired while charging.)

* ACTION-426: Draft the proposed design of getting rid of battery{low,critical} and adding a field that indicates state=ok/low/critical

The same argument as above: firing less events is better for performance, thus I propose we keep the current design.

* Implemented the following change noted by Francois: "level changes by at least 1 (i.e. removing "%" since the scale is from 0 to 100)".

One more thing (should not block CfC for LC though):

* There was discussion on Geolocation WG ML about Device Orientation and bringing back window.on* handlers, Doug also recently implemented those to Firefox:


Those handlers were removed from Battery Status Events spec couple of revisions back as per Doug's request:


Should we pave the newly established cowpath and revert that change? 

As always, let me know if there are any concerns with these changes, if you have better proposals, or if I missed some of the remaining issues or actions. Otherwise, I'd be happy to CfC.

Received on Thursday, 18 August 2011 11:55:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:49 UTC