W3C

List of comments on “Battery Status API” (dated 29 November 2011)

Quick access to

There are 6 comments (sorted by their types, and the section they are about).

question comments

Comment LC-2575
Commenter: Anne van Kesteren <annevk@opera.com> (archived message)
Context: in
assigned to Anssi Kostiainen
Resolution status:

Should there be some kind of privacy section? I guess you cannot tell much
from someone charging his phone, but maybe in conjunction with other data
you can find patterns of some kind. Fingerprinting is probably also
somewhat aided by this functionality.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-2577
Commenter: Carr, Wayne <wayne.carr@intel.com> (archived message)
Context: 4. BatteryManager Interface [NoInterfaceObject] interface...
It appears that changes in the Last Call draft have made it so there is no way to distinguish between a full battery and no battery being present. Was the ability to detect a battery being present intentionally removed?

>-----Original Message-----
>From: Dominique Hazael-Massieux [mailto:dom@w3.org]
>Sent: Tuesday, November 29, 2011 8:25 AM
>To: public-device-apis@w3.org
>Cc: public-device-status@w3.org
>Subject: Battery API in Last Call
>
>Hi,
>
>The Battery Status API was published today as a Last Call Working Draft:
>http://www.w3.org/TR/2011/WD-battery-status-20111129/

>
>Please send comments regarding this document to public-device-apis@w3.org ;
>the last call period ends on December 20 2011.
>
>Dom
>
>
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2606
Commenter: Marcos Caceres <w3c@marcosc.com> (archived message)
Context: in
assigned to Anssi Kostiainen
Resolution status:

Note that [TreatNonCallableAsNull] is still in flux in WebIDL. I strongly recommend emailing the WebIDL list about this for guidance before proceeding (might save a bit of a headache later).
(...)
the event name is not memorable… bike shed discussion, I know… but the event names are not ideal IMO.
(...)
I'll note that it seems pretty extreme to have four different event registers that basically do the same thing: detecting a change in charge. Why don't you merge them into a "onchange" attribute? Also, the spec says that BatteryManager is an EventHandler, yet no events are fired at it (that seems wrong - event handlers need to have events fired at them)?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2574
Commenter: Anne van Kesteren <annevk@opera.com> (archived message)
Context: 4. BatteryManager Interface [NoInterfaceObject] interface...
assigned to Anssi Kostiainen
Resolution status:

The events need to be queued using the task queue defined in HTML5. It
should probably be worded in such a way that the attribute is updated and
the event is dispatched in the same task so nothing else can observe the
attribute having changed before the event is dispatched.

You also need to actually define the various on* attributes as being event
handlers and update their IDL to match the latest crazy IDL syntax (which
might be simplified, so maybe you want to wait for that).

Should there be some kind of privacy section? I guess you cannot tell much
from someone charging his phone, but maybe in conjunction with other data
you can find patterns of some kind. Fingerprinting is probably also
somewhat aided by this functionality.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2576
Commenter: Sergiu Dumitriu <sergiu.dumitriu@gmail.com> (archived message)
Context: 4. BatteryManager Interface [NoInterfaceObject] interface...
assigned to Anssi Kostiainen
Resolution status:

An extra editorial comment: in the BatteryManager interface, the level
attribute should be listed after the dischargingTime attribute, to be in
line with the order of their definition, and since it's a more logical
order to keep charging and discharging time together.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2580
Commenter: Carr, Wayne <wayne.carr@intel.com> (archived message)
Context: 4. BatteryManager Interface [NoInterfaceObject] interface...
assigned to Anssi Kostiainen
Resolution status:

Separating this from detecting battery presence thread and restating the problem.

Problem with draft: Suppose the battery is full and the user disconnects the power. The battery is now in use and is discharging. The Battery API Last Call draft [1] requires the charging attribute to be set to true, even though the battery is actually discharging. That is an error in the spec.


Current text for charging attribute: "The attribute must be set to false if the battery is discharging, and set to true, if the battery is charging, full, the implementation is unable to report the state, or there is no battery attached to the system, or otherwise.

No exceptions."



Suggested text for charging attribute: "The attribute must be set to false if the battery is discharging, and set to true if the battery is charging. If the implementation is unable to determine the state or there is no battery attached to the system or for any other state not explicitly defined, the attribute must be set to true. No exceptions."

A Boolean probably isn’t the best thing here. Enumeration of {charging, discharging, unknown} is an alternate fix.

[1] http://www.w3.org/TR/battery-status/
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org