The batterystatus can be unimportant for pages or apps. Or, detail info is needed more than this.
But, before the spec is changed, I think there is no problem to support this. It is better to support to do not. Can you be sure that this will be not used? I think It is good to support to someone try to use this for their apps or pages after spec is published, if it is lacked or not enough now. 2011/6/18 Eric Seidel <e...@webkit.org> > Given how many desktop applications do this, I think we're well off > into the land of wishes and fairy tales. :) > > But it's also possible that libraries like jquery or Google's closure > could do this... but again, I'm skeptical. Then again, if we don't > expose information like this, they don't ever have a chance to prove > me wrong. > > -eric > > On Fri, Jun 17, 2011 at 10:54 AM, Darin Fisher <da...@chromium.org> wrote: > > I think there are web app developers that would do things differently if > > they > > knew their user was running on battery power. An app might scale back > its > > CPU usage, or run a timer at a lower frequency. Crazy idea: Maybe an > > advertising network could be "nice" and not show animated ads to such > > users? ;-) > > -Darin > > > > On Fri, Jun 17, 2011 at 10:47 AM, Eric Seidel <e...@webkit.org> wrote: > >> > >> My 2ยข: > >> > >> I'm confused by who the client of this API would be. > >> > >> It seems that "web sites" don't really need to know my battery state. > >> But "web applications" that are on mobile phone (like WebOS, or > >> Apple's original vision for iPhone apps) would want battery state > >> information, but would want *more* information than this spec provides > >> (imagine trying to write any power-management application like the > >> zillion examples available for Apple's Dashboard, or iPhone). > >> > >> I'm also not sure that I want all web sites knowing this information. > >> I wonder what fingerprinting vectors this API would expose (if any?). > >> Certainly websites could know if their visitors are laptop users or > >> not (but I suspect they can already figure that out from screen size > >> and UA strings). > >> > >> It's also possible that I'm just spreading FUD here, and that smarter > >> people than I have already hashed this all out on the spec list... > >> > >> -eric > >> > >> On Fri, Jun 17, 2011 at 10:40 AM, Darin Fisher <da...@chromium.org> > wrote: > >> > > >> > > >> > On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu <andr...@google.com> > >> > wrote: > >> >> > >> >> On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher <da...@chromium.org> > >> >> wrote: > >> >> > > >> >> > > >> >> > On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen > >> >> > <anssi.kostiai...@nokia.com> wrote: > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> On 16.6.2011, at 19.02, ext Darin Fisher wrote: > >> >> >> > > >> >> >> > On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen > >> >> >> > <anssi.kostiai...@nokia.com> wrote: > >> >> >> > > >> >> >> > On 15.6.2011, at 21.29, ext Darin Fisher wrote: > >> >> >> > > >> >> >> > > There should probably be a way to poll the current state. > Much > >> >> >> > > as > >> >> >> > > you > >> >> >> > > can poll the document.readyState and respond to progress > events, > >> >> >> > > it > >> >> >> > > would > >> >> >> > > seem to make sense to have a way to poll the battery state as > >> >> >> > > well > >> >> >> > > as > >> >> >> > > respond to battery state change events. > >> >> >> > > >> >> >> > The current design is quite similar to that of the Device > >> >> >> > Orientation > >> >> >> > Event. We discussed the polling option but settled on the > current > >> >> >> > design. > >> >> >> > Let me know if you'd like me to dig into archives for some > >> >> >> > pointers > >> >> >> > on that > >> >> >> > design decision. > >> >> >> > > >> >> >> > I'd be curious to read them. Off-hand it seems like device > >> >> >> > orientation > >> >> >> > suffers from the same problem. You wouldn't want the > application > >> >> >> > to > >> >> >> > do too > >> >> >> > much work that would be discarded once it finds out that the > >> >> >> > orientation is > >> >> >> > X instead of Y. > >> >> >> > >> >> >> I think the design guidelines introduced in the following Mozilla > >> >> >> position > >> >> >> paper are still valid. In this context, specifically: > >> >> >> > >> >> >> [[ > >> >> >> > >> >> >> Device APIs should be asynchronous; in particular, user agents > >> >> >> should > >> >> >> not > >> >> >> have to block on return values of Device API function calls, and > >> >> >> Device > >> >> >> APIs > >> >> >> should be driven by callbacks. > >> >> >> > >> >> >> > http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous > >> >> >> > >> >> >> ]] > >> >> > > >> >> > The proposal wasn't to make blocking APIs that query any devices. > >> >> > Instead, > >> >> > you would be able to get synchronous access to the last known value > >> >> > for > >> >> > a > >> >> > device property ("last known battery state", "last known device > >> >> > orientation", etc.). In particular, you would get access to the > last > >> >> > known > >> >> > value prior to your page being loaded. > >> >> > Synchronous access to this value seems helpful for the reasons > stated > >> >> > in > >> >> > this thread. But, let me expand on that for a moment. Suppose an > >> >> > application wanted to know both the battery state and the device > >> >> > orientation > >> >> > before generating its content. It would need to asynchronously > query > >> >> > both > >> >> > states before proceeding. That seems quite awkward, especially > when > >> >> > the > >> >> > information could be provided synchronously. > >> >> > > >> >> > >> >> In the case of device orientation, having such a synchronous property > >> >> would probably mean having the UA do a lot of wasted work, constantly > >> >> exercising the underlying hardware just in case some Web app might > >> >> need this information at start-up. However, I think it's reasonable > to > >> >> expect that Web apps using this API will be built in such a way that > >> >> they will do work in response to orientation changes, so it's perhaps > >> >> natural for them to treat the initial orientation the same way. > >> >> > >> > > >> > That's a good point. > >> > I guess I feel less strongly about orientation events, especially > since > >> > there is such a large continuum of states. Whereas with battery > state, > >> > there are fewer states and less frequent changes. > >> > navigator.onLine and the online/offline events are somewhat comparable > >> > to battery state in my opinion. Both change at a relatively low > >> > frequency. > >> > -Darin > >> > > >> > _______________________________________________ > >> > webkit-dev mailing list > >> > webkit-dev@lists.webkit.org > >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >> > > >> > > >> _______________________________________________ > >> webkit-dev mailing list > >> webkit-dev@lists.webkit.org > >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev