W3C

Disposition of comments for the Device APIs Working Group

paged view

Not all comments have been marked as replied to. The disposition of comments is not complete.

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

CommentorCommentWorking Group decisionCommentor reply
LC-2574 Anne van Kesteren <annevk@opera.com> (archived comment)
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.
(1) http://lists.w3.org/Archives/Public/public-device-apis/2011Dec/0013.html yes
LC-2606 Marcos Caceres <w3c@marcosc.com> (archived comment)
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)?
Double-checked on WebIDL, no changes. Marcos agreed to the resolution:
http://lists.w3.org/Archives/Public/public-device-apis/2012Apr/0036.html ("Thanks again, and nice work!")
yes
LC-2575 Anne van Kesteren <annevk@opera.com> (archived comment)
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.
Privacy considerations section added to editors draft, see http://dvcs.w3.org/hg/dap/raw-file/tip/battery/Overview.html#security-and-privacy-considerations yes
LC-2580 Carr, Wayne <wayne.carr@intel.com> (archived comment)
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/
from http://lists.w3.org/Archives/Public/public-device-status/2011Dec/0014.html

Wouldn't dropping "full" from the true condition fix this. "Otherwise" will catch the case "neither charging nor discharging". My proposal:

[[

charging of type boolean, readonly

Represents if the system's battery is charging. The attribute must be set to false if the battery is discharging, and set to true, if the battery is charging, the implementation is unable to report the state, or there is no battery attached to the system, or otherwise.

]]

http://lists.w3.org/Archives/Public/public-device-status/2011Dec/0016.html
yes
LC-2576 Sergiu Dumitriu <sergiu.dumitriu@gmail.com> (archived comment)
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.
http://lists.w3.org/Archives/Public/public-device-apis/2011Nov/0261.html

Fixed, see:

http://dev.w3.org/2009/dap/system-info/battery-status.html
yes

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: doc.php,v 1.36 2014-02-19 08:10:56 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org