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

Hi,

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:

  http://dev.w3.org/cvsweb/2009/dap/system-info/battery-status.html.diff?r1=1.32;r2=1.33;f=h

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

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

  http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0009.html

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:

  http://www.w3.org/TR/html-design-principles/#priority-of-constituencies

(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:

  http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0017.html

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

  http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0058.html

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.

-Anssi

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