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

Hi,

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.

-Anssi

Received on Wednesday, 14 September 2011 11:55:00 UTC