On Flash Killers

There’s a common problem in each of these recent quotes… matter of fact, there are two problems, a smaller one and a larger one:

“Actually, canvas is an HTML 5 standard, not a proprietary solution. It’s a peer to any other feature of HTML.” [link]

“There are huge differences between canvas and Flash: canvas IS an open standard (see HTML5) and there are multiple interoperable implementations, even multiple excellent open-source implementations.” [link]

“If you needed further evidence that Apple will never allow Flash to sully its portable Internet devices, then 3D CSS transforms are it. Along with WebKit’s support for HTML 5’s advanced media handling capabilities, advanced Nitro JavaScript engine, and CSS-based transforms and animations, Apple is readying WebKit to be the best tool for providing web-based applications on a wide variety of platforms… If Apple enables the features on the desktop, they could kickstart the development of a whole new class of visually rich web applications, without Flash.” [link]

“Safari was the first web browser to support HTML Canvas, and the standard is now supported by most popular browsers.” [link]

“With Safari 4, and the upcoming Firefox 3.1, we’re going to see the beginning of the end for Flash. Why is this? One word, ‘Canvas’.” [link]

“We want standards that make it possible to do everything that Flash does.” [link]

The smaller problem? People who say “CANVAS is an open HTML5 standard” either do realize they’re speaking mendaciously, or do not realize they’re speaking mendaciously, or maybe-sorta realize they’re speaking mendaciously. There is no “HTML5 standard”, only a process which might potentially lead to a Recommendation but more plausibly would lead to something like HTML 3, XHTML or ECMAScript 4. And its history doesn’t seem very open.

Read through Sam Ruby’s timeline or Doug Crockford’s desire to see a larger context for why advertising “CANVAS is an open HTML5 standard” is so strange. But that’s a smaller problem.

The bigger problem? Technologies which define themselves by what other technologies already provide tend not to do as well as those technologies which seek a novel, fitting and sustainable place in their larger ecology. There are opportunity costs for needless opposition.

SVG is the poster child. The idea for it originated about the same time as Flash appeared. It was even the very first W3C Recommendation. As a way to express curves in documents it still has potential. But its fans pushed it in competition with Flash, and feature proposals kept increasing. Now 14 years later its use is still stunted.

Silverlight was hailed as Flash Killer. They haven’t been able to meet those expectations. Silverlight still has potential for cross-browser deployment of .NET applications and Windows Media workflows. But the earlier hype has made its path more difficult.

VIDEO tag is another… the different actors in the consortium couldn’t even agree on basics like codecs, and leave absent metadata support, production workflows, streaming and multicast, much less two-way video communication. Even if the HTML5 process was “finished” tomorrow morning instead of in 2022, do you see any way it could be deployed in the world?

All of these “Flash Killers” have their fans — you’ll hear voices on both sides of such a debate. But over time, the “lookit what i can code!” crowd fades before the larger number of people actually trying to use the technology. Focusing on the smaller technical details does not replace considering the larger surrounding ecology of real people employing the technology.

Being defined in terms of an existing standard diverts a potential technology from its most fortuitous growth within the ecology. SVG collapsed under its own weight. The Silverlight wishlist is the current Flash feature list. And expanding the requirements for any hypertext browser to be its own full multimedia runtime will, at best, just crowd out diversity within browser development — no more room for a small startup like Firefox to be born.

Look at how a technology can best be used. Seek out unique advantages which it alone can provide. Look beyond the code, to realworld usage. Be yourself.

I think HTML5 should improve hypertext use. Figure out how to solve the printing problem, the font problem, the mobile problem, the accessibility problem, the semantic problem. The World Wide Web was created for linking physics papers, yet still cannot display them! Think of why Berners-Lee did not just use SGML. Reduce the learning curve, make it easier for anyone to learn how to publish — focus fiercely on lowering the barriers to communication.

Open up your browsers to third-party plugins — fix WMODE visual integration, and fix NPRuntime scripting integration. Figure out the EMBED/OBJECT/VIDEO business, and agree on background-TAB CPU privileges and accessibility hooks. And if you could open up your Prefs UI to plugins (for an integrated user experience) then that would be great too.

You’ll need some type of cross-browser ability yourself, if you ever want to offer new features beyond your current browser marketshare! So make it easier for other people to add standard support to your rendering capabilities. Let Adobe and others help provide realworld people a universal choice, spanning browser brands. Browsers and plugins are naturally synergistic, so be a part of the ecology which surrounds you.

But most of all, clean up hypertext. That’s what the 5.0 version of the Hypertext Markup Language should do. Don’t get distracted. Clean up hypertext.

We can’t afford HTML5 to be called a “Flash Killer”, then fail. We all need hypertext to succeed.