W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2011

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

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Wed, 14 Sep 2011 14:54:13 +0300
Cc: "<Frederick.Hirsch@nokia.com>" <Frederick.Hirsch@nokia.com>, <public-device-apis@w3.org>
Message-Id: <3D0121DE-0369-4868-985C-19B5438502AE@nokia.com>
To: ext Robin Berjon <robin@berjon.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:46:05 UTC