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