Which makes it far more complicated. Another occasion where it’s appropriate to say “Fuck you, Google!” (also fuck you for disabling audio/video control on chrome mobile from JS, EXCEPT for google.com/youtube.com etc)
Perhaps this would be a good time to advocate link shorteners that use the standard HTTP redirect mechanism (bit.ly is one of them), so they can be HEAD'ed, and not some additional layer of obfuscation either via meta-redirect or (even worse) bury the target in some minified and obfuscated JS.
I have an IRCbot that is supposed to resolve URLs and find out if they ever end up on YouTube, and then post the video title, length and viewcount.
It was an extreme hassle to implement all of this, I am partially parsing JS and the DOM just to get all those redirect services to work. It’s a huge hacky mess, but the only fast working solution.
And, for the fifth time today, I can sincerely say “Fuck you, Google!”
They don't want that because they don't want them to be automatically resolved so they can do metrics which is like 99% of the reason they are used in electronic form.
Not if the intermediary, say, Twitter, de-shortens the link once, and then sends all the real traffic to the cached destination URLS. Not that they do that at the moment.
In Chrome mobile you can only do for example .play() on an audio or video element, if you call it from an eventListener that reacted to an onClick event.
Well, yes. You have to initiate things that could cause bandwidth use from a user interaction instead of, say, a timeout or an XHR or a DOMContentLoaded. youtube follows the same rules as everywhere else: it doesn't autoplay. Unless you're unwittingly opening youtube urls in the app instead of chrome.
iOS on the other hand actually -does- initiate bandwidth use on a <video> element, even if no interaction has taken place. If you watch Charles during an iOS video session, you will see 2-3 HTTP GETs before you even initiate playback. This can play merry hell if with your HTTP logs, if you pay attention to that sort of thing.
iOS also has major issues with multiple <video> elements; <video> must be full-screen on non-tablet i-devices (you cannot create custom controls); you cannot control volume via the user interface; it uses a nonstandard progression for its status-related events... (and sometimes they're just plain missing)...
I've spent the past few years working on web media players for mobile and desktop ;) I kind of know what I'm talking about. And due to its position in the marketplace, iOS Safari has stagnated - it's easier to get HTML5 multimedia working correctly in IE11 than iOS Safari. iOS Safari is the new IE6.
Has an API too: http://longurl.org/api