Disposition of comments for the Device and Sensors Working Group

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.

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)?

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.

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/

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.