Earlier today I took a certain amount of pleasure ripping into Jon Dowdell’s disingenuous Adobe on HTML5 post from last week. However, I happen to think that there are some useful points to be made about the relationship between Flash and HTML5, and how one affects the other.

It doesn’t look good for Flash. But Flash isn’t going to die.

Firstly, consider some background. Flash has been around for a very long time, providing a platform for games, vector graphics, animation and media playback. It offers massive market penetration, and of course there is only one Flash player, so it purports to offer a consistent experience across platforms.

However, Flash comes with a number of significant downsides. Firstly, that ‘consistent experience across platforms’ might also be written as ‘inconsistent experiences on every platform’. By taking most of its user interface conventions from Microsoft Windows, the experience of using Flash on a Mac is not the same as using any other app in OSX using native controls. Simple stuff like the behaviour of keyboard chords in text entry controls are different, the text selection colour doesn’t match the system selection; low level stuff.

Similarly, the Flash plug-in itself is cited by Google and Apple as being a massive cause of crashes in their browsers, crashes that the browser maker gets the blame for, but is really caused by Flash. In Google Chrome and in OSX Snow Leopard, plug-ins are sandboxed away from the main browser process. Mozilla lists Flash as the biggest causes of Firefox crashes on Linux.

To top it off, for all the claims of ‘Accessible Flash’ over the past year, Flash content is still only accessible on Windows; on Mac OSX, Flash has no integration with VoiceOver. Screen readers are only supported on Microsoft Windows through the MSAA API.

The iPhone shipped two years ago without Flash support. At the time, some said it was a ‘missing feature’. 24 months later, the iPhone seems to be doing just fine without Flash, and users seem very happy. Adobe have stopped making vapourous comments about having ‘Flash for iPhone’ waiting in the wings.

There are two distinct threads to a Flash vs. HTML 5 discussion. Those are ‘Features’ and ‘Philosophy’. Let’s tackle them separately.

Features

HTML 5 is gaining mind-share because of a handful of key new features that it offers: <video>, <audio> and <canvas>.

The first two are quite self-explanatory, they are new elements dedicated to providing video and audio media directly in the browser, and provides a DOM API for controlling the media from JavaScript. Note, the idea is that the media is played back directly by the browser, not through a plug-in like Quicktime or Windows Media Player (which is how video used to work, before Flash).

This affects Flash because over the past few years, perfectly timed with the rise in available bandwidth to stream audio and video, it provided a solution better than the Quicktime/Windows Media/RealPlayer mangle that came before it. Before, to embed video in pages you needed to provide multiple codecs, depend on bespoke media player UI appearing in your page (all of which was different sizes, and so would break your layout), and half the time your visitors had the wrong version of the plug-in anyway.

Flash stepped in with a solution: Support for more platforms than any one of the other bespoke players, and you could design your own playback UI around it, too.

Flash won video from under the feet of Apple, Microsoft and Real by building something that was better, and bypassing their squabbling over codecs.

But, it’s just a better, bespoke solution. It’s still vendor dependent. Flash provided the use-case for ‘embedding video with author-defined playback controls’. The purpose of standardisation is to take that feature and define it, such that anyone can implement it. From there, comes video and audio in HTML5.

Flash also provides vector drawing tools. It’s another useful use-case (graphing, interactive charts, etc.) Again, the standardisation process for HTML is about taking the use cases from real content on the web and defining it so many people can implement it. canvas (via. Apple) is the implementation for that.

Three major pieces of functionality. Putting them natively into the browser responds to the needs of web developers. That’s what the standard is for. Does this mean that HTML 5 ‘kills’ Flash because previously Flash-only functionality is now native? No. But it means that those major use cases no-longer require Flash. There’s plenty of other, less trivial functionality that Flash supports for which widespread demand does not exist. But of course really common features of web pages are going to be supported in Open Web technology.

Additionally, you may cite sifr — using custom typefaces — as a use-case for Flash. That falls outside of HTML5, but is covered by an increasingly well supported CSS3 feature, @font-face.

Philosophy

I’ve avoided linking Jon Dowdell here as a major source because although he titled his post ‘Adobe on HTML5’, his blog also states that his opinions do not represent his company. His post is representative of Adobe’s general philosophy toward the web, though.

As far as Adobe are concerned, Flash is part of the web. It’s not just an optional, bolt-on plug-in for proprietary content. To Adobe, Flash is as much a part of the web as JavaScript or CSS. They regard is as a legitimate part of the stack.

“the “HTML5” publicity helps marginalize those few who still argue that images, animation, audio/video and rich interactivity have no place on the web. Flash will be able to deliver on those heightened expectations, regardless of what each separate browser engine does.”

The second part of Adobe’s philosophy is that consistent support for functionality on the web is non-negotiable.

“we really do need the ability to predictably deploy advanced capability across a range of device brands and browser brands”

This philosophy is wrong. One: Flash is not part of the web. The web is the Open Web and anything closed and proprietary is just riding on its back. I don’t mean that bespoke plug-ins are unwelcome or even ‘wrong’; they provide all sorts of useful functionality. I do mean that if you are a single-vendor creator of a proprietary, patent and license encumbered, undocumented, closed-source plug-in then you have no claim to be part of the infrastructure of the web. The infrastructure, from TCP/IP upwards, is open.

The consistent support aspect also flies in the face of techniques used with every part of the Open Web stack: Graceful degradation, progressive enhancement, and the fight against the misguided demand for pixel perfection are all battles that have been fought and won since Designing for Web Standards.

The web is about content. Everything above that is dressing (perhaps think of the web as fresh bread, perfectly coated in balsamic vinegar and olive oil). The fact that older browsers cannot render all the features of your page but can still provide the content to users is a feature. It’s the most important feature.

The Flash philosophy is opposite. Flash is about a complete experience (singular). It’s about every detail being precisely bevelled into place for every viewer. The consequence of this approach is that it resists the availability of content. The goal of perfect consistent rendering can only be achieved through a single version of this single vendor’s bespoke plug-in. If you need a feature of Flash 10, Flash 9 users must upgrade to see any of your content, not just the new feature.

The Flash approach is anti-content; anti-web. Adobe present the idea that Flash is a superior offering because the entire suite of features, in one big blob, is a compelling development offering. But the reason to write on the web in the first place is to make content available broadly.

In recent years, through multimedia, fonts and and vector drawing, we’ve seen more and more blocks of content moved into Flash, in the absence of a robust standards-based mechanism. HTML5 redresses that by supporting those use cases. HTML4 supports pictures. HTML5 supports moving pictures. HTML5 supports what people publish on the web.

Fuss

What is the fuss about? HTML5 doesn’t compete with Flash as a product, (you could never produce an implementable specification for so much functionality in one go). It just takes some specific, common use-cases for web content and supports them.

Yet, people on one side are crying for the absolute death of Flash, and clearly some from Adobe are on the defensive to outright dismiss the HTML5 effort.

Critics may be motivated by any number of those negative user-experiences this article opened with, but Flash won’t die. If HTML5 takes away one use-case that Flash fulfils, Adobe Flash will add new features that browsers don’t have. That’s what plug-ins have always done. Flash can and will iterate faster than browsers and can deploy wider all at once. That said, some of those existing use cases — namely video playback — are extremely lucrative for Adobe. Video took Flash from ‘optional’ to ‘essential’ for a certain slice of web content. The video sharing industry is dependent on Flash.

Adobe will lose their exclusive grip on that. But, what did they expect? That a massively profitable industry would tie themselves to a single vendor?

Flash offers only one advantage to video on the web, and I think this one will be genuinely interesting to see turned into a marketed feature. The HTML5 method of embedding video looks like this:

<video src='http://example.org/video/foo.mp4'></video>

There’s the URL to your video file, right there in the HTML source, downloaded in raw form. What can Adobe offer publishers? Two ‘features’ of software that run absolutely counter to the principals of the open web: DRM and obfuscation.

That could be interesting. The survival of Adobe Flash Video online will require them to take the closed, anti-content consequence of Flash’s model, and instead embrace it as a feature for media companies that fear distribution of their content.

Really, I think this whole issue is overblown. Maybe it’s all fuelled by scare-mongering from individuals Adobe, maybe it’s over-eager Open Web evangelists eager to see closed and proprietary scraped from the face of the web. In reality, it’s just the pragmatic, ongoing evolution of the web offering useful new functionality.

Social Web FooCamp was a full two weeks ago, and even now I’m not entirely sure the lessons of this meeting have entirely sunk in. Surrounded by some of the smartest people in the industry (and other influential oddballs), FooCamp provided a backdrop to see friends and rivals come together and share.

I was there for my work with microformats, and as someone who periodically pops up to suggest improving the user experience of OAuth.

People

MySpace, Facebook, Yahoo, Google, OAuth, Portable Contacts, Activity Streams, Open Social and OpenID. All under one roof. Everyone quite keen to move in positive directions. An exciting mix.

It was quite something to spend two days in these surroundings, participating in the conversations that determine what happens next. As is my nature though, perhaps the biggest value came through observation and listening. And to cut to the chase, herein lies my principal learning of Foocamp:

The Open Stack needs a Product

Foo had many, many sessions on the Open Stack; OpenID, OAuth, OpenSocial and Portable Contacts. Some of them concerned with user experience, some with data portability and distributed identity, some with the processes of open development itself. Every single one of those sessions at the very least mentioned Facebook. But more often, the sessions were outright dominated by Facebook Connect.

A session on building a start-up on the Open Stack was turned into a discussion about Facebook’s product, and what developers wanted from it.

Note the emphasis on Facebook’s product. The way in which we classify the technology of the open, social web and compare it to Facebook Connect is massively flawed.

Get this clear: Facebook Connect, from inception through API through user experience, is a single, self-contained, beautifully packaged product for developers. And it’s awesome. Facebook has the combination of detailed, well maintained user data, a huge user-base and excellent user interface design for the Connect experience. It ticks every box.

Compare to ‘the Open Stack’. There is no product. These are technologies — wonderful technologies — with which you could build something with the functionality of Facebook Connect. But at time of writing, there is no mature offering. The branded products from Yahoo and Google are not as strong as Facebook; they’re less mature in every way. Problematically, though, the tools have a stronger brand than the implementations.

It’s this that causes the Facebook/Open Web comparison to fall down so quickly. The open technologies are right and true. Using the same open auth and identity protocols is a massive win for developers. But what are you actually implementing?

The open stack itself doesn’t contain any data, nor provide any service. It is just the mechanism to provide those services. You don’t solve anything by ‘integrating OAuth’. OAuth isn’t a service. The publicity has to shift to actual service providers, where the end users are involved. Because really, it’s touching those end users that drives developers, not beautiful snowflakes.

We’re all imagining a world where you can implement OpenID+OAuth+PoCo and seamlessly integrate with Google, Yahoo! and any other social network using the same code. But that doesn’t exist yet. Only the foundations of it exist. And without the data provision from actual products, there’s no implementation to focus the open stack discussion on.

Not broken

Whilst it all sounds a bit bleak, nothing here is broken. Facebook has a massive head-start in the marketplace. Yahoo, Google, MySpace et al are playing catch-up in terms of the APIs and the user experiences of their own sites. Is Yahoo! Updates as rich an experience as Facebook? Not yet, no. There’s work happening everywhere to compete, across all aspects of all services. As such, of course Facebook is the more compelling option this year; it’s obvious that’s the case.

Further, as evidenced by Facebook’s Open Stream API launch last week, their strategy has been formidably well planned. Over the past twelve months they’ve been hit with sticks by openness advocates for being locked away in their walled garden, but their priorities have been elsewhere. They’ve been building a rock solid foundation that, once in place (now), they can start to open up and offer good data from the start. They have the luxury of the market lead, and they can use that to release better, more complete services. That’s their reward for being first, and they’ve earned it.

So, the feeling I come out with is that we should stop thinking about Facebook in the context of open standards (except where they implement them, of course). It’s a broken comparison. It’s hard, because the competitors have everything in the air at once, but it’s down to them over the coming months to turn their adolescent, open-powered APIs into compelling products. The part OAuth plays in this is just to continue becoming as transparent to users as possible.

It’s not the job of OAuth and OpenID as part of this ‘Open Stack’ to take on Facebook in mindshare. The roles of these APIs (PoCo, Open Social and Activity Streams included) is to be expected and taken for granted in any new implementation. These are the bricks on which houses are built. But people don’t buy bricks, and so our eyes need to focus on the products of this work.

The other point to stress here is that whilst the open stack needs stronger implementations, they don’t have to be ‘NotFacebook Connect’. That’s only one use for these standards. The big Open Web offering could be somewhat different. Better, even.

Be excited. The struggle of Open standards vs. Facebook is a fallacy, they’re just efforts a little out of sync. This year, with maturing, big products powered by open technologies, we’ll see things built that extend beyond the achievements of Facebook’s walled garden age. MySpace, Google, Yahoo! et al are all moving together toward something quite special. Developers will be able to take on exciting new, provider agnostic apps with this technology. Just accept that the second generation of competitors need a little time and encouragement to build out.

Oh, and don’t be surprised to see Facebook active in all this, too. In the end, they’ll be as open as anyone else.