
More HTML5 APIs - davidwalshblog
http://davidwalsh.name/more-html5-apis
======
pygy_
From an advertiser'a point of view, the visibility API is a boon. For users
not so much.

I've recently noticed several sites that pause their video ads when the tab is
hidden.

I don't look at adds. I have several ad jingles/slogans from my youth wired in
my brain. They popon cue, and since I don't want to add new ones to my
collection, I now actively avoid ads.

This means that I now have to look elsewhere while the video is playing, or
hide the screen, and it annoys me to no end.

/rant.

To browser authors:

This feature has some use, but a huge potential for user abuse. It would be
most helpful if it were possible disable the API, or to enable it selectively
on a site by site basis.

~~~
eli
I think I'm missing something. Wouldn't the alternative be to keep playing the
video ad even when you're not looking at it? Why is that better? I don't want
my browser wasting cycles to render a video it knows I can't see.

At the risk of stating the obvious, it sounds like you have a problem with
ads, not a problem with the visibility API.

~~~
pygy_
Meanwhile you can do useful/less annoying stuff in other tabs.

And I have a problem with ads that are forced on me, true, my case may be
extreme, but I'm sure that it annoys other people too.

~~~
eli
Depending on your browser, that seems pretty doable with a plugin. I assumed
ad block plugins would nuke video ads anyway -- is the issue that they are
preroll and hard to filter?

At the risk of getting into an ethics debate, that's sort of the deal being
offered by the publisher: you get the content in exchange for watching this
ad.

------
FuzzyDunlop
I've been writing a library that abstracts the getUserMedia API, and I've
found it really interesting to be able to use JS and HTML to interact with
hardware in a (mostly) simple way.

Even though I prefer the native implementation of these things, the pure
creativity HTML and JS allows (because it's less difficult) is where these
features really shine. Calling WebRTC "skype in a browser" is just the tip of
the iceberg.

------
andrethegiant
Could someone explain to me a use case for the battery API? I can't think of a
single situation where it would be beneficial. The article states that you can
detect if a user's battery is low to avoid battery-intensive processes, but do
you think developers are going to spend their time inflating their scripts to
deliver a poorer web experience to their users just because they have a low
battery?

~~~
quarterto
Save prompts when the battery is low?

~~~
Zigurd
Quick poll: Which is worse...

a) Battery-aware HTML5 apps

b) Having a save command

~~~
quarterto
Ok, what about more frequent autosaves?

~~~
Zigurd
Android's APIs enable easy implementation of a sqlite-based data model, where
changes are always persisted.

That doesn't solve the problem for things like CAD that need an in-memory
object-oriented data model, but the Android support for observer patterns can
be wrapped around any data model, and the ability to quickly, which means, in
practice, incrementally, persist changes is driven by both Android-specific
issues like needing to respond to lifecycle events quickly, and by general
mobile considerations like a battery that could fail unexpectedly.

In other words, you need to solve the "don't explicitly save" problem for
reasons ranging from "it's more robust" to "it fits Android UI conventions"
anyway.

------
Arceliapfa
Nice! I like the link prefetchin

~~~
tonywok
Yeah, definitely going to try that out my next mobile app. Great article.

~~~
true_religion
However, I think its only supported on Mozilla Firefox.

I used to support it on my media sites when Mozilla was topdog, but since the
share is split between Chrome/IE I no longer do so.

~~~
dbaupp
Does it hurt to support it? As in, why did you stop supporting it if the
infrastructure was already there?

~~~
true_religion
Oh its not that. When I re-wrote the pages, or upgraded services, I just
stopped including/thinking about prefetching for Firefox.

So it pretty rapidly disappeared from all the sites that I support/operate.

------
discordance
For the curious:

Fullscreen API works on Safari, Firefox and Chrome.

Page Visibility works on Chrome and Firefox.

getUserMedia (camera access) works on Chrome Canary and Opera

Tested on latest public releases; Safari 6.02, Chrome 23.0.1271.64 and Firefox
16.0.2

~~~
bzbarsky
getUserMedia (alas, prefixed) should also work in Firefox, generally
speaking... Though maybe it's preffed off by default? The patch for it landed
for Firefox 15: <https://bugzilla.mozilla.org/show_bug.cgi?id=752353>

------
achal
:( No love for the Audio API? <http://www.w3.org/TR/webaudio/>

(Admittedly, it's only supported in Webkit at the time)

~~~
kevingadd
That is pretty much why, I'd expect. Though Mozilla apparently have plans to
integrate it in Firefox, at which point you could probably start using it in
HTML5 apps in the wild!

------
sergiotapia
I really look forward to the media and prefetching API's. They seem really
needed, and now that I've read about them, I wish I could use them in
production.

~~~
eli
Well, you can rel="prefetch" it just won't do anything unless you're using
Firefox (AFAIK).

~~~
emmelaich
Is there a privacy vulnerability with prefetching? I can imagine timing it and
making inferences about whether it's been cached and therefore previously
visited.

~~~
eli
Possibly true, but I'm pretty sure you can already do that with something like
<img onload="someJavascript()">

------
MatthewPhillips
I hope they start to provide, when appropriate, non-JavaScript APIs for some
of these things. Full screen is one that could be useful.

~~~
emddudley
Non-JavaScript? Like what?

~~~
flebron
Say, <a href="foo" fullscreen="true">, I'd guess.

~~~
MatthewPhillips
Probably something new would have to be invented as there is no mechanism to
send messages to the browser in plain html. Something equivalent of a form
element but without the action attribute. It would be nice to have something
like (spitballing)

    
    
      <some-new-form>
        <input type="hidden" value="fullscreen" />
        <input type="submit" value="Go fullscreen" />
      </some-new-form>

~~~
detst
> Probably something new would have to be invented as there is no mechanism to
> send messages to the browser in plain html.

Web components. At least their usage is plain HTML and could do what you want
internally with the JS API.

------
scottfr
I opened up the developer console on Chrome and copied in his code to make the
whole page full-screened. It doesn't seem to do anything and doesn't show an
error message.

Is there an issue with the code? I know Chrome supports the full-screen API.

~~~
bmuon
It needs user interaction to start. Have you tried using a button?

~~~
scottfr
Thanks, that must be it.

------
OlavHN
PeerConnection is an API now enabled in vanilla Chrome.

<http://www.webrtc.org/blog/seeyouontheweb>

------
taitems
Interesting fact learnt from the Phonegap creator at Web Directions: calls to
the battery API actually decrease battery life.

------
monsterix
Good that this came in just when I was playing with the Fullscreen API. It is
the Firefox's implementation of this that's bothering me.

Figured out that we have to put up with a hack to avoid the default
"background:black" that Firefox applies to the element being pulled to
full_screen mode. But what is worse is that Firefox kills y-scrolling
completely for pages longer than screen-height.

In effect one can't have full_page rendering (like on iPad or in normal state
of browsers) of the website in full_screen mode of Firefox. That's seriously
crippling.

How do we tackle this? Is there any enlightened soul who got this done
already? Or I am hitting the wall, right now?

~~~
kevin_p
Sounds pretty stupid, but it sounds like you should be able to get round it by
sticking everything in a scrollable wrapper div (height:100%; overflow:scroll)
when fullscreen mode gets activated. Or just do things the old fashioned way
and tell the user to hit F11 (or apple-shift-F on mac) to put their browser
into manual full-screen mode, which supports scrolling.

~~~
monsterix
I did try this. I don't remember this exactly, but what was happening then is
that only the visible part of the page came in to the F11 wrapper div. There
no-scroll in the full-screen browser window.

In effect you're left with an option to introduce scrolls within content divs,
and that looked worse. Chrome on the other hand manages this quite nicely.

------
pyrotechnick
<http://html5please.com>

