- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Fri, 21 Oct 2011 10:35:01 +0300
- To: public-device-status@w3.org, "Chan Cathy (Nokia-CIC/Boston)" <Cathy.Chan@nokia.com>
Hi, On 20.10.2011, at 22.27, Chan Cathy (Nokia-CIC/Boston) wrote: > Two quick questions outside of the discussion on the representation of the > no-battery case in the other thread. > > Currently the spec says that if the implementation is unable to report the > charging state, chargingState must be set to "full". In what situation then > will the value of "unknown" be used? I think we should perhaps try to get rid of the 'unknown' state altogether and default to 'full'. I updated the prose accordingly. IMHO, the 'chargingState' should be consistent in the following cases: * the device does not have a battery (e.g. desktop), * the implementation is unable to report the battery's level, or * the battery is there and it is full. The use case I had in mind was the following: a web-based game queries navigator.battery.chargingState synchronously upfront before branching to high performance or reduced version, something like: if (navigator.battery.chargingState === 'full') { // use WebGL } else { // use less flashy [sic] version } It is still pretty much open whether we want to go 'chargingState' of type DOMString or if 'charging' of type boolean would be enough. It seems Mounir initially implemented the 'charging' boolean only. The same with boolean: if (navigator.battery.charging) { // ... } else { // ... } Does someone have high value use cases in mind for 'chargingState', or should we just go with the simpler 'charging' of type boolean? It may sound a bit unintuitive to say charging === true, if there's no battery in the system, but I could live with that. > The value of remaining is to be set to positive infinity on a couple of > occasions. Since the attribute is a long, would it be more accurate to state > the exact value to be used instead? After all, one can't really represent > positive infinity with a long (or can we?). I changed the type of 'remaining' to double, which should be able to handle 64 bit IEEE 754 floating point numbers, and JavaScript Infinity property (Number.POSITIVE_INFINITY or Infinity in short). > Also one small typo: towards the end of Section 3.2 just before the Issue > box, "When the value of charging, level, ...", s/charging/chargingState/. Fixed. Thanks for the feedback! -Anssi
Received on Friday, 21 October 2011 07:35:50 UTC