Adobe kills off (mobile) Flash
(Source: shirt.woot)
The writing was on the wall long before Adobe shifted its interactive focus to HTML5/CSS3, offering up resources like Wallaby, Edge, the expressive web and so on. Steve Jobs was prescient—and perhaps instrumental in helping Adobe realign themselves—in offering his insight into the problem:
Flash was created during the PC era – for PCs and mice. Flash is a successful business for Adobe, and we can understand why they want to push it beyond PCs. But the mobile era is about low power devices, touch interfaces and open web standards – all areas where Flash falls short. […]
New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.
Browser plugins like Flash became widespread because there were no native alternatives. Prior to HTML5 video and recent advancements in CSS and JS, if you wanted to put a movie or interactive elements on your webpage, you had to use Flash. And in doing so, you generally had to compromise by tolerating a shorter battery life, a louder GPU fan, a slower computer, a hotter-to-the-touch laptop, and stuttering video. Having gone Flash-free for almost a year now, I can say you only notice how much better things are after you’ve gone cold-turkey.
On mobile, this suboptimal performance is unacceptable; but shouldn’t it be the same for desktop? To this end, Marco Arment posits:
If web developers must make non-Flash implementations of everything, why bother making the Flash versions at all? This isn’t just the death of mobile Flash: it’s a confirmation from Adobe that all Flash is on its way out.
I’d like to hone in on this observation by making one of my own: in hindsight, embedding Flash into a webpage has always been kind of awkward. Here’s some sample code from a Flash embed, with added bolding around the most relevant bits:
<object
classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com
/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0"
width="400" height="300" id="movie" align="">
<param name="movie" value="movie.swf">
<embed src="movie.swf" quality="high" width="400" height="300" name="movie" align="" type="application/x-shockwave-flash"
pluginspage="http://www.macromedia.com/go/getflashplayer">
</object>
Including spaces, that’s 441 characters used when only 34 (the bolded characters) are necessary. It’s verbose, hard to remember, and inelegant. Looking at some HTML5 equivalents, this shortcoming becomes clearer:
1<embed src="movie.swf" />
2<video src="movie.mp4" />
3<video>
<source src="movie.mp4" />
<source src="movie.webm" />
</video>
My point is that implementing Flash feels complicated and unnatural. It’s unfortunate that developers have had to live with it for years. Thankfully, embracing HTML5 presents the perfect opportunity to leave it all behind.
Flash to HTML5… or not: Rick Cabanier of Adobe demos upcoming .fla export to HTML at MAX 2010.
In principle, this is excellent: seamless workflow, reuse of symbols, minimal scripting for the code-phobic. The problem? It’s not HTML5, even though it’s being billed as such. Here’s the evidence:
It’s XHTML 1.0 Strict, CSS3 Animations (probably), JS and SVG. The output is also a heavy mess of divitis and tag soup. It’s clear that Adobe is jockeying for the position of HTML5 flag-bearer by obfuscating the definition of “HTML5” for the general public. This behavior is old hat, but it certainly reveals a lot about Adobe’s web strategy.
Either way, this sleight-of-hand is alarming and disingenuous. I’m one of the countless designers who would love an easy workflow for exporting Flash animations to HTML5 Canvas/JS, but I can do without animations if it means bogging down my code with a 2-ton elephant of inefficient code soup.
I have higher hopes for Adobe Edge, but only because it fills the specific need for a web animation front-end.
Poison Apple from Shirt.Woot was too punny to pass up. Bought one.
/via gizmodo
Fallback from Flash to HTML5 video for iPad/iPhone Support
In a recent post, Jeremy Keith explains how the “HTML5 video vs. Flash” dichotomy is nonsensical:
Frankly, I’m a little baffled by this supposed dichotomy because you don’t have to choose. The way that
videoworks, according to the spec, is for fallback content to be placed between the opening and closingvideotags. So you can go ahead and useobjectorembedor whatever you need to put your Flash video in your markup. Browsers that understand thevideoelement will use that while less capable browsers will play the Flash movie in theobjectelement (and because of the way theobjectelement works, you can put yet another layer of fallback content between the opening and closingobjecttags).
What this boils down to is: what are you trying to achieve?
If the answer is “cross-browser HTML5 video (with Flash fallback)”, then a solution along the lines of Kroc Camen’s Video for Everybody is perfectly suitable. By taking this approach, you are implicitly acknowledging that the Flash container is suboptimal for delivering video to the browser, and you will only engage it if necessary.
If the answer is “enabling existing Flash video to play on the iPad/iPhone”, then the above solution is overkill. By far, the most appropriate solution is to embed Flash video as usual (via object for most browsers, and embed for Firefox) and fall back to HTML5 video for Mobile Safari (iPad/iPhone/iPod Touch).
So, borrowing some conventions used by Jeremy in his write-up, here is an example of code that falls back from Flash to HTML5 video to a download link:
<object data="flashplayer.swf?video=file.flv" width="640" height="480">
<param name="movie" value="flashplayer.swf?video=file.flv">
<embed src="flashplayer.swf?video=file.flv" width="640" height="480" />
<video controls src="file.mp4" poster="file.jpg" width="640" height="480">
<p>Download video:<a href="file.mp4">MP4</a></p>
</video>
</object>
If you want to see this example in action, please view the demo.
The cost of this implementation is converting the existing FLV to an MP4, hosting the MP4, and adding the HTML5 video code at the end of the object tag. If you’ve previously been serving up Flash video, the only changes are that
- visitors on Mobile Safari will now be able to play your videos, and
- visitors without Flash who are not on Mobile Safari will now be able to download your videos.
If you’re happy with delivering Flash video to your visitors but don’t want to exclude Mobile Safari visitors, this is an extremely robust solution that lets you take a step forward without mandating a leap of faith (in HTML5 video performance/patents/support).
Should I Make a Flash Site?
This one’s an oldie-but-goodie. The discussion re: SEO and accessibility was always a trying one to have, but thankfully, the iPhone/iPad and web technologies have advanced to the point where this is a much easier conversation to have.
Site note: I can’t believe no one has this single-serving site yet.
Flash Comes to the iPad via RipCode
This is (at best) a stop-gap solution in a transitionary period where people are afraid to move to devices that lack Flash capabilities. What RipCode does is intercept the Flash video request as the page is loading, transcodes the video in the cloud and delivers it as MP4 to the in-page container.
It requires buy-in from the page owners though, which may hinder potentially viral adoption. What might be a better workflow is to trade some of that seamlessness for accessibility. If I could run a bookmarklet on a page with Flash video, choose which video I’d like to transcode, and then have a new page open up with the video playable as MP4, that would be ideal — ideal enough that I wouldn’t care if I had to wait 1-2 minutes longer for the payoff.
ZOMBO
I somehow forgot about the craziness of this Flash intro. Oh old school memes… your nostalgic effect is unrivaled.
