W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2014

Re: [battery] Battery Editors Draft update needed to prepare for LC

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Mon, 9 Jun 2014 13:28:11 +0000
To: Mounir Lamouri <mounir@lamouri.fr>, "cathy.chan@nokia.com" <cathy.chan@nokia.com>
CC: W3C APIs WG Device <public-device-apis@w3.org>
Message-ID: <70534332-7AB5-440E-A662-7C7F6231ACC0@intel.com>
On 09 Jun 2014, at 13:17, Mounir Lamouri <mounir@lamouri.fr> wrote:

> On Sat, 7 Jun 2014, at 8:04, cathy.chan@nokia.com wrote:
>> A few comments on the changes...
>> In Section 5 Navigator Interface, the second step says 
>> [[
>> If those steps were previously successfully run in the current browsing
>> context ...
>> ]]
>> It is not clear what "those steps" refer to. "these steps" would actually
>> be more accurate. Alternatively, consider something like "If an instance
>> of BatteryManager has previously been created in the current browsing
>> context..."
> Done.

>> In Section 6 BatteryManager Interface, the following two statements are
>> conflicting with regard to what the value of chargingTime should be when
>> the implementation is unable to report it:
>> [[
>> When a BatteryManager object is created, if the implementation is unable
>> to report the battery's charging state, charging time, level or remaining
>> time, charging MUST be set to true, ***chargingTime to 0***, level to 1.0
>> and dischargingTime to the value positive Infinity respectively.
>> ]]

The defaults spec'd herein emulate fully charged battery. This means that with these defaults, the experience is the same as if the device had full battery.

>> [[
>> The chargingTime attribute MUST be set to 0, if the battery is full or
>> there is no battery attached to the system, and ***to the value positive
>> Infinity if the battery is discharging, the implementation is unable to
>> report the remaining charging time***, or otherwise.
>> ]]

This should align with the defaults described above assuming we want to still emulate the full battery, thus chargingTime must be 0 if the implementation is unable to report the remaining charging time.

Mounir - WDYT? How do the implementations comply with the above proposal?

>> I don't remember which one was the agreed behavior, but would note that
>> the latter one works well in the multiple batteries scenario as
>> described. If the former one is used, the multiple batteries description
>> might need more tweaks.

Cathy - what are the clarification needed to support multiple batteries?

> So, the confusion is that when the battery is charging but not full and
> the system can't report the charging time, it should report it as
> Infinity. I added that precision.

>> While we're looking at the attributes of BatteryManager, I would suggest
>> swapping the order of the sentences within each paragraph. Begin with
>> what the attribute represents, followed by how its value should be set.
>> For example:
>> [[
>> The charging attribute represents the charging state of the system's
>> battery. It 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. When the battery charging state is updated, the user agent
>> MUST queue a task which sets the charging attribute's value and fires a
>> simple event named chargingchange at the BatteryManager object.
>> ]]
>> It reads more naturally.
> Hmm, I am not sure what to do here. It is purely editorial and Anssi
> wrote that originally so I would prefer to let him decide how to change
> the wording.

I moved all the descriptive text into its own paragraph after the IDL block:


>> In Examples 3 and 4:
>> 	navigator.getBattery(function(battery) {
>> should be 
>> 	navigator.getBattery().then(function(battery) {
> Good catch ;)
>> Finally, clearly just a nit...
>> In Example 1 & 2, clearTimeout(...) should be clearInterval(...).
> Eh, that wasn't part of my changes but yes indeed :)



> Thank you for the great feedback Cathy!

Indeed, thanks! Please review the changes.

Received on Monday, 9 June 2014 13:29:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC