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.
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.)
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.
Say, something with more than a few dozen frames?
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.
Seems like a terrible use of time.
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).
Which sounds very wise from a user perspective.
Imagine every crappy web advertiser auto playing videos on page load on Mobile Safari. Yuck.
I don't want videos to auto-play on my Laptop, why would I want them on my phone?
>Curse you iOS 4.3 for taking away our simulated clicks
Simulated clicks? I rest my case...
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.
There is a whole pattern of similar things like this in web that is killing me a little bit every day.
Want to center a div on the page? No worries just wrap it in these 5 divs and apply these 20 css properties and you are good to go. Oh btw, IE doesn't like that, you need this.
Honestly I think we developers should stop putting up with crap like this, and accepting the burden of broken technologies using hacks, etc...
If we become less tolerant of crap, there will be less crap. As long as we accept it by using workarounds, etc... there will be more shitty things to come.
If you need IE8+ support, there is also display:table and family.
Not the best link, but here's some more recent info: http://css-tricks.com/old-flexbox-and-new-flexbox/
Text scaling can be a PITA though.
Honestly I think Microsoft has the best developer toolkit in the business right now but they haven't yet had the product design prowess to put that technology in the consumer's hands in any significant numbers.
Margin Auto w/ a fixed width
Absolute 50% w/ negative margins
Text-align center parent w/ inline-block display on children
If it was sarcasm, disregard my stupidity.
The whole thing feels like you are stretching something beyond what it was intended to be used for.
Things like element positioning should be so so simple that if you search about it, you get nothing back because no one had a problem to ask for solutions.
Although I must say I'm not mocking CSS in particular, most web technologies feel this way because they were designed many years ago for a web that was supposed to have simple 'documents' like an article, text and paragraphs and today each component of it is expected to do a lot more.
It's not getting all that much better either because each new version and improvement is building on top of the previous decisions, etc...
> most web technologies feel this way
> It's not getting all that much better either because each
> new version and improvement is building on top of the
> previous decisions
Container has fixed dimensions in my example, but it does not matter in this case.
Btw. your approach is exactly same that we had 10 years ago but with CSS table behavior faking rather than table tag.
It's like variables (yeah I know, LESS / SASS ...).
Yes, totally intuitive and logical solutions all of them.
If you have w3c Stockholm syndrome, that is.
E.g "Just absolute 50% it with a negative margin" (oh, yes, and you would have to know the width beforehand).
>If it was sarcasm, disregard my stupidity.
It's not the stupidity, is the willingness to put up with BS convoluted inelegant workarounds for lack of basic, bread and butter, features.
If you value elegant APIs, KISS and DSLs, you should run screaming in the opposite direction in all those three, horrible, horrible, techniques.
W3C first came up with their (broken) model, and then they kludged solutions to use cases with it, instead of starting from the use cases first. That's why we have had the tables before and the need for the flexbox and grid layout now.
You're right, there is a willingness to put up with it. Mainly because I understand how these solutions work, how to debug them, and make everything nice and peachy. Do I wish things were better? Of course! Who wouldn't?
Apple's JS disables the animation for iOS 4.x and below, so maybe that's why it wasn't playing on your friend's iPod.
I see Apple is really embracing the idea of "the one web" here, introducing web-fragmentation even among their own devices.
Apple has long stopped impressing me. Back in the days when they were the clear underdogs, they were for web-standards and a unified web, because they saw how that was good, and that was what allowed them to become what they are now.
Now it seems they don't really have so much ideological issues with how web-pages should be built anymore. Funny thing that.
That doesn't seem true. The second-most-prominent links on the iPhone and iPad sites are to videos that only play in Quicktime. If they wanted the site to work everywhere, they'd use a format those browsers can natively play.
QuickTime is never required.
There is no <video> tag, there is a "Get Quicktime" button, no video plays in my Chrome browser, and here's a screenshot of the network tab showing it downloaded a .MOV file with content-type movie/quicktime, not h.264: http://i.imgur.com/h8dO8.png
How do you propose I watch this QuickTime video without QuickTime? Have you forgotten the context of this conversation, about the purported desire to support all major browsers?
The keynote and Johnny Ive video are a little different because it's targeted towards people who are already Apple enthusiasts. They're much more likely to already have Safari or QuickTime installed (or at east be willing to install it).
Still, it does strike me as kind of odd that Apple is working so hard to make one video accessible while being pretty lazy with another one (they don't even bother to make it accessible to Chrome on Windows, which does have h.264 support, unless QuickTime is installed). Maybe those two parts of the site were prepared by different teams.
[EDIT]: Actually, I just tried again in Chome and IE 9 on Windows 7, and it works fine (without QuickTime installed). Maybe Apple fixed it?
Using a technology you probably already have to own an iPad or an iPhone to have installed no less.
What I'm really curious about is how those images are being generated. Is there a tool already available for that?
Sublime's example does highlight a solid usecase for this technique that Apple's example doesn't really emphasize: <canvas> + JS video compression is still the only way to do this stuff losslessly, which is pretty important for what Sublime is doing.
Just want to mention it before we blurt out the obvious over-engineering argument. ;)
It's just that downloading a bulky app for something you'll use infrequently is a crappy way to to business.
That said, perhaps they could integrate the two a bit better.
It's ludicrously shortsighted, you'd actually think they'd want to make it easy for people with competitor products to buy from Apple not harder!
This would probably some of what people want here.
About the last paragraph, we (Adinpsz) tried the PNG compression technique for JS demomaking (actually it's even a self-loading PNG-HTML ;)).
And see it in action here: http://pouet.net/prod.php?which=59071 (http://adinpsz.org/online/fabrik/)
But HTTP compression should be better anyway for "real world" usecases?
I worked at Blizzard. On the Blizzard web pages.
So, good work! I think you're cool :)
For example, how does the _frames array of base64 data related to the two unlock_00X.jpg files? All it says is "The "unlock_manifest.json" file specifies how the updated parts are positioned."
Surprisingly, there is no mechanism to explicitly state which blocks to get from the JPEG. Instead, it always just uses the next unused blocks. (This means that blocks from the JPEG cannot be reused.)
H.264 would emit "skip" macroblocks for everything except the area that was changing (probably near the cursor). The repetition of "skip" would be easily compressed.
I immediately thought of web1.0 sites of 1990-s, with lots of animated gifs floating around. Weird times.
This was more along the lines of, "How Apple reinvented/over-engineered the animated GIF"
I went ahead and added a really short byline though.
Obviously this is absurd overengineering.
And, despite the assumed total cross-browser compatibility claimed, I found that the video wouldn't play in any browser available to me, despite pinning the CPUs on my computer while just sitting there doing nothing.
Preventing download and viewing doesn't seem very important to me. Anyone could just use one of many screen recording apps to get good enough copies anyway if they wanted them for some reason, and who cares if they do have them.