Re: [battery] Alternative design proposal (was: addEventListener side effects, ordering & boundary crossing ...)

Hi,

On 14.9.2011, at 14.54, ext Anssi Kostiainen wrote:

> On 12.9.2011, at 12.45, ext Robin Berjon wrote:
> 
>> Right, I think that if the implementation supports the battery spec, it should always expose some information about battery — even when there is no battery to speak of. The question is how to represent this? Is {isPlugged: true, level: null } or {isPlugged: true, level: -1 } enough? Is it confusing? Should we add a hasBattery field, which would be weird but accurate?
> 
> Do you have a nice use case in mind that makes use of the distinction between "unable to report the level" and "there's no battery"?
> 
> Now the spec says: "If the implementation is unable to report the battery's level, then level must be set to null." which covers both the cases.

As agreed on the call couple of minutes ago, I clarified this in the spec:

  http://dev.w3.org/cvsweb/2009/dap/system-info/battery-status.html.diff?r1=1.53;r2=1.54;f=h

So level=null if there's no battery or the implementation is unable to report the level.

Robin - Now we should be ready to publish a heartbeat.

-Anssi

Received on Wednesday, 14 September 2011 14:36:54 UTC