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.
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.
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.
It's better because the user doesn't have to sit on that tab waiting for the ad to play out. How it currently is one can go check Facebook or HN (or even do some work!) while waiting for the ad to finish.
To move beyond the ad issue. Maybe I'm not interested in watching the video (say a presentation) but only listen to it. Then I have a legitimate reason for not wanting the video to pause: doing other work in other tabs.
Which is why it's good for marketers but not the user. I don't need to see the same ad more than once in a session but many video sites will display the same handful of ads every couple minutes. This is especially prevalent on twitch.tv when watching gamers stream, it's usually the same ad every time. After the first time I see it I'll just visit another tab while it's playing (mind you the audio is still playing.) If they were to pause while I was doing this I wouldn't bother watching at all.
I like to open videos of talks an play them while I do other browsing and work. I still am listening just not watching. If the video stops when I move away, now I can't have my background sound be interesting info about $TOPIC.
As a feature, I think it has a lot of merit. Advertisers will love it, as it actually improves on TV ads (which you can fast forward through easily).
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).
This is what I'm most afraid of. Ads are starting to quickly plague the internet. They've already screwed up TV and made it completely unwatchable and internet is next. YouTube is already extremely annoying to navigate.
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?
Wow... I can think of few ways to completely destroy goodwill with users than that. If someone has decided that they aren't interested in listening to an ad, enough so to spend the time to lower the volume, you sure as hell are not going to elicit warm fuzzy feelings by actively ignoring their wishes.
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.
That sounds like an argument for better ad blocking, not an argument for less rich web APIs. Avoiding new web APIs because ads might use them seems like avoiding new OS APIs because malware might use them; better not to run the ads/malware in the first place.
See, this is what I don't understand about HTML5. Wasn't executing untrusted code the purpose of operating systems ? Now we're having two layer of APIs like you said. Browser APIs and OS APIs. And we're seeing weird (or awesome) things like Emscripten, Native Client and Chrome OS.
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.
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?
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.
I think its a step in the correct version if HTML5 is every able to compete with native apps on mobile. HTML5 needs better access to hardware elements. We can see two out of these five here - the camera and battery level.
The one way in which web apps still cannot compete effectively on mobile and which gets no attention is access to a user's contacts/address book.
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.
HTML 5 games can show battery status, or warn when the battery is running low. HTML 5 apps can suggest that the user save their work as they are running low on power, to name a few.
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
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!
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.
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.
I don't see how you would be able to tell how long it takes to load- unless you control the site it's prefetching, in which case you should be able to tell if they've been there before anyway.
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)
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.
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?
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.
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.
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.