Nice to see they're getting bit by their own decisions.
They've gone out of their way to ensure that you can't ever play an Audio/Video clip automatically on page load in iOS Safari. Every new iOS release for the first few years included a patch to kill any new workarounds that let you do so. (Curse you iOS 4.3 for taking away our simulated clicks.)
But now they have a use case of their own that needs it, so they invent the mother of all workarounds. And now the rest of us will start using it. And it will become the "standard" way to run video on iOS Safari.
Then they'll kill it off for iOS 7. Then they'll have to come up with an even crazier workaround so that they can render their own website a few months later.
Thing is, it's not a video.
It's a glorified animated gif.
This has almost nothing to do with autoplay and the video tag and much more to do with a desire for a script-controllable animation.
(Most obviously: they don't start playing until the animation data is loaded, so that it doesn't do the herky-jerky frame-playing during load, like actual animated gifs.)
> This has almost nothing to do with autoplay and the video tag and much more to do with a desire for a script-controllable animation.
Yes it does. Apple has disallowed you to play a video on iOS without user action. So it would not be possible for the video to autoplay (even with the scroll trigger). HTML5 supports preload and has the canplaythrough event which allows you to avoid buffering. They went through this rigamarole because they have previously decided developers should not be able to do this.
It would be unfeasible to do so. Assuming the displayed image is a reasonable size, say a dimension of 320x240, you would run out of pixel space in a jpeg due to dimension limitations after about 38 minutes @ 24fps. Granted, that's not using the manifest, just straight skipping around in the sprite.
To make this anywhere near possible on a large scale would be feasible though. The easiest way would to be create the manifest while encoding the video. Take the same compression scheme but save the encoding diffs for every frame.
Apple's manifest supports spreading the video across several images (the spinning earphones use this).
Real-world video (filmed with a camcorder, not just a screencast) of any length probably wouldn't work well at all with this compression scheme, though. Apple's JS video compression basically only optimizes out parts of the image that don't change at all. If you're filming the "real world", pretty much every 8x8 block in each frame is going to have changes (it's basically guaranteed due to sensor noise, lightbulbs flickering, etc).
How do you know they feel they're getting 'bit'? Maybe they think this is the optimal solution for what they are trying to accomplish? Maybe they have an internal tool for generating the images they need to accomplish these things? Maybe it's "smooth as butter", as they would say, on their side?
There's a reason that we have video codecs like mpeg and h264 instead of using mjpeg for everything; the compression is much better. In that sense, a stream of jpegs is far from optimal, even if it's smooth as butter on a fast connection.
>What do you do when that happens on your laptop? You close the page and move on.
No, I proactively install apps such as "Click to flash" and the like to make sure this DOES NOT happen on my laptop.
>Why does it need to be any different on your mobile/tablet? I assume the battery cost of 2 seconds of video loading/playing once in a long time is negligible.
Because I could be anywhere surfing with my mobile/tablet, in the dentist's office or even in a meeting. I don't want pages to jump at me with video I have not requested. Ever.
And I don't want web marketers to assume anything about the battery life cost of their actions on MY devices.
I disagree with the person above you's "negligible" comment. From what I understand, there is a significant battery difference for Android games between ad-supported free and ad-free paid. And the difference is due to all the extra radio usage for advertisements.
What do you do when that happens on your laptop? You close the page and move on. Why does it need to be any different on your mobile/tablet? I assume the battery cost of 2 seconds of video loading/playing once in a long time is negligible.
They've gone out of their way to ensure that you can't ever play an Audio/Video clip automatically on page load in iOS Safari. Every new iOS release for the first few years included a patch to kill any new workarounds that let you do so. (Curse you iOS 4.3 for taking away our simulated clicks.)
But now they have a use case of their own that needs it, so they invent the mother of all workarounds. And now the rest of us will start using it. And it will become the "standard" way to run video on iOS Safari.
Then they'll kill it off for iOS 7. Then they'll have to come up with an even crazier workaround so that they can render their own website a few months later.
Fascinating to watch this play out.