More HTML5 APIs
davidwalsh.name
davidwalsh.name
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.
Now that you tell it I actually reverse engineered a page (script compiled with GWT, strings mangled, most of the script being one or two letter variables, often the same ones), to find out how they were doing it, and in that case, they were using document or window.onblur.
I tried to overwrite the event handlers without success.
At the risk of stating the obvious, it sounds like you have a problem with ads, not a problem with the visibility API.
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.
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.
.. besides not using commercial ads and instead using image / text ones that take up much less precious bandwidth.
Couldn't me do more with less here ?
In MULTICS, sure. Not in Unix/Windows/Mac.
That may actually be a Flash thing.
I've recently gotten to the habit of having two browsing windows open. If in one of them I stumble across something that forces me to watch 30 seconds of ad (which happens increasingly often), I flip focus, continue browsing something else and come back to the other window later.
It's great to hear they can now start to ensure I watch the ads. What's next, API that checks if you have system sound muted or too low?
If you're already using some kind of ad-block, there's nothing stopping you/your ad block from disabling the visibility API on select pages (youtube et. al). It's a Javascript API, and that means you'll be able to alter its functionality fairly easily (bookmarklet, plugin, addon, etc).
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.
a) Battery-aware HTML5 apps
b) Having a save command
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.
As part of this, they're adding API's to provide the sort of hooks that mobile apps need, such as being aware of battery status.
They would also like these to be standardized across all browsers, so that HTML apps can properly compete with "native" apps.
Right now on the web Facebook and convoluted non-standard APIs to your email provider are pretty the only way to get access to contacts. This is the number one barrier to allowing web apps to spread easily when a user wants to share the app or something in the app with a friend.
You could query the API, if they've got <50% battery left, adjust the draw distance to decrease rendering for longer play.
It's very niche, but along with video games, i'm sure some novel hacker will find a use for it!
A perfectly reasonable example is a Twitter client that switches from auto-refreshing to manual refresh when the battery is low.
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.
So it pretty rapidly disappeared from all the sites that I support/operate.
Minor nitpick: prefetching is not an API. Still cool, though.
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
(Admittedly, it's only supported in Webkit at the time)
<some-new-form>
<input type="hidden" value="fullscreen" />
<input type="submit" value="Go fullscreen" />
</some-new-form>Web components. At least their usage is plain HTML and could do what you want internally with the JS API.
Is there an issue with the code? I know Chrome supports the full-screen API.
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?
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.