- From: Robin Berjon <robin@berjon.com>
- Date: Mon, 21 Nov 2011 12:24:10 +0100
- To: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Cc: public-device-status@w3.org
On Nov 21, 2011, at 12:14 , Anssi Kostiainen wrote: > On 18.11.2011, at 12.44, ext Mounir Lamouri wrote: >> I tend to agree. Then, shall we add an attribute to the BatteryManager object that explicitly says if there is a battery in the device? > > DOM API has had hasFeature() and isSupported() for quite some time, but AFAIK the methods are not widely used (for various reasons). The "various reasons" being that they have failed spectacularly at being useful over the past fifteen years or so. There are many documented instances of hasFeature() returning true for features not supported (or not completely supported), and the converse of them returning false for features that actually work. The core problem with these meta indicators is that the second that one of them in one version of one implementation is broken, you're out in the cold. The only way of making them truly reliable is by farming them off to an external entity that checks the UA for you. We happen to have that: it's called Modernizr :) I know that the presence of a battery is different from the presence of a feature, but it seems very related in terms of failure scenarios. > I think authors would still go with the established practice of feature detecting based on functional parts of the API (see e.g. [1]) instead of relying on the .hasBattery. +1 Let's ship this lean and mean! If in a few months' time we get feedback from developers that hasBattery would be dead useful, then it's trivial to add it and iterate through a new spec release. If we add it now and it turns out to be useless, that's a dead code branch that might have to stay there in perpetuity... -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 21 November 2011 11:24:37 UTC