4 ms·

FWIW the battery api was first specified when people were still hoping that building phone widgets, launchers etc would be done with web technologies. For such

by chucky 8y ago

FWIW the battery api was first specified when people were still hoping that building phone widgets, launchers etc would be done with web technologies. For such usage, having battery api access in a standard way was of course a necessity. In a wider sense, there are legitimate uses for many of these apis. To me it seems like the option would be that some phones would get these apis patched into the browser by the manufacturers instead, and that would run an even higher risk of security problems than when the browser vendors do it. If you don't like your browser application having access to certain hardware in your phone, you can just revoke the permission, and it won't have the access (at least on Android, I have no idea how iOS works in this regard).

gsnedders 8y ago
> FWIW the battery api was first specified when people were still hoping that building phone widgets, launchers etc would be done with web technologies. For such usage, having battery api access in a standard way was of course a necessity. And it was done by Mozilla people working on FFOS, specifically. They had no intention of exposing it to web content IIRC.
- earthscienceman 8y ago
  I still see FFOS as ahead of its time. I really wish it would have worked out better.There's all this jostelling happening between the role of software based apps vs. the role of web content/apps on devices... but in the end every day I see more and more content being served through the web. As browser integration improves (through things like 'web bluetooth') I think we're creeping more closely to the browser essentially being an app sandbox for your hardware/OS. Now, whether this is good or not is left as an exercise to the reader.
tinus_hn 8y ago
I think the original idea was that background JavaScript apps could suspend operations when your battery is running low. It quite an edge case but it’s one of those things that make a web app less than native.

by chucky 8y ago

gsnedders 8y ago

> FWIW the battery api was first specified when people were still hoping that building phone widgets, launchers etc would be done with web technologies. For such usage, having battery api access in a standard way was of course a necessity. And it was done by Mozilla people working on FFOS, specifically. They had no intention of exposing it to web content IIRC.

earthscienceman 8y ago
I still see FFOS as ahead of its time. I really wish it would have worked out better.There's all this jostelling happening between the role of software based apps vs. the role of web content/apps on devices... but in the end every day I see more and more content being served through the web. As browser integration improves (through things like 'web bluetooth') I think we're creeping more closely to the browser essentially being an app sandbox for your hardware/OS. Now, whether this is good or not is left as an exercise to the reader.

tinus_hn 8y ago

I think the original idea was that background JavaScript apps could suspend operations when your battery is running low. It quite an edge case but it’s one of those things that make a web app less than native.