Re: Battery Status API Last Call Feedback ( LC-2574)

Hi Anne,

Thanks for your LC comments! It took me a while to get back to you as I was away for a while.

On 4.1.2012, at 12.47, ext Anne van Kesteren wrote:

> On Tue, 03 Jan 2012 16:39:37 +0100, <> wrote:
>> Please review it carefully and let us know by email at
>> if you agree with it or not before 10 January
>> 2012. In case of disagreement, you are requested to provide a specific
>> solution for or a path to a consensus with the Working Group. If such a
>> consensus cannot be achieved, you will be given the opportunity to raise a formal objection which will then be reviewed by the Director during the
>> transition of this document to the next stage in the W3C Recommendation
>> Track.
> I think it is okay, but I also think could be clearer still. In particular:
> * Conformance requirements with respect to the attributes could be merged. E.g. "The attribute must be set to false if the battery is discharging" and "When the battery charging state is updated, the user agent must queue a task which sets the charging attribute's value" would be better if all the requirements where in the latter statement and you would just define the attribute as returning its value.

Fixed. Your proposal seems much clearer to me.

> * In the list of attributes event handler attributes are listed as well, except they are not defined there. They are defined in the next subsection. Somewhat duplicitous if you ask me.

I think I borrowed this grouping from one of your specs, perhaps from XHR:

... but ReSpec.js automatically creates and populates the Attributes section, thus there are stubs such as:


onchargingchange of type Function, nullable
No exceptions.


Those stubs are indeed a bit redundant. Given that we migrated to even more awesome ReSpec.js v2, those may be configurable. Robin?

Anyway, we may also get rid of the Event handlers section -- whatever is the best practice works for me.

Here's the latest spec:

And the changeset:

Thanks again! Let us know if something else needs fixin'


Received on Thursday, 9 February 2012 10:46:55 UTC