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.

10 Responses to On Flash Killers

  1. karl says:

    Fact checking only.
    Did the license of Flash changed in a way that makes it openly implementable by anyone without licensing fees?
    Is there an open technical specification (not patent encumbered) for flash?
    If there is a “no” answer to these two questions, I think the crux of the issue is here. We agree that the contest on technologies is quite futile.
    [jd sez: Hi Karl — many of the openable technologies have been opened, see openscreenproject.org. But audio and video codecs are the rub — Adobe pays licensing fees to distribute H.264 and other decoders, and cannot grant sublicensing to others, so “reimplementation” is tough. When running code on other people’s machines, predictability trumps customization — Flash complements browsers and their “PNG-alpha” variability.]

  2. stelt says:

    People try to stuff new (to them) things in mental boxes. Often (first?) in old boxes. That doesn’t help in getting things clear.
    Taking the original content of a box and saying “this is the best, all the others don’t fit” is really comparing boxes, not content.
    In other words, ideas and technologies overlap. Does one fully replace another? rarely and never quickly. Though many compete and all have their pros/cons also dependent on who you ask (for taste/payroll reasons among others).
    SVG is used a lot, more and more even (world conference at Google this year …). Is it seriously competing with Flash? Of course. Is it winning? In some areas certainly. Is it killing Flash? Not any time soon. I hope not. I believe Flash ‘the tools’ are pretty good quality that many people enjoy, or have become part of. Flash ‘the format’ has some less though, though not many care actually.
    On HTML5. Will we have a full HTML5 standard ready and implemented completely and perfectly any time really soon? No.
    Are we even in these rather early stages seeing some video tags showing up used for content? yes. Will a significant number of people start using them any time soon (starting say right after Safari4, Opera10 and Firefox3.5 are released). Oh yes, certainly. Will some big video sites switch? Not fully, not so fast, but some certainly will eventually. Does this all mean HTML5 is a Flash killer? Far from it. Does this mean HTML5 will strongly change where Flash is used? Oh yes.
    I try thinking outside the box.

  3. Excellent article… my basic opinion is use the tool most suited for the job. HTML is great for hypertext and form editing… Flash is great at animation and multimedia. HTML can not be a killer based on like the fact that Flash can use video card resources for rending while a browser can’t and that Flash has a great keyframe animation system.

  4. karl says:

    hmm I see a lot of “®” in the Web site, you sent me and nothing much helping to discuss the issues.
    video and audio codecs are an issue which is a lot wider than any html 5 and flash. It is orthogonal. It is not only a software issue, there is a device issue which is a lot harder to solve (mobile phone hardware for decoding videos and possible submarine patent).
    So Flash doesn’t solve interoperability issues either. Here you are making the mistake you are reproaching others ;). I can find many tools which are not usable with flash. Flash does cool things in some areas and is not appropriate in others.
    My initial comment still stands 🙂

  5. foresmac says:

    Just to be fair, I didn’t call HTML5 a “flash killer.”
    It’s clear from Apple’s own behavior they would just as well be happy with a web without Flash. Many of the common uses of Flash on the web can easily be replaced by some of all of a combination of technologies, including video and audio tags in HTML5, Canvas, CSS-based transforms, and JavaScript. I believe Apple is content to follow that direction.

  6. Ethan Estes says:

    I’m still waiting for all the flash killers to explain how it’s cheaper and easier to do all my multimedia elearning in ‘open-standards’. I hear all this crud about ‘We want standards that make it possible to do everything that Flash does.’ I suggest those people get their degrees in computer sciences and start building the browser that can (sarcasm implied.) OR you could just download the flex sdk and download flash develop for free and get to work.
    Flash owns my desktop because i can get billable work done in it fast. Html 5 will take YEARS to be fully implemented in all the browsers, meanwhile i can get a consistent playback in the flash players across browsers and os’s. I can even say to heck with those browsers and use the webkit in the air runtime.
    If at some point it gets there and i can make money then great-but don’t downplay the importance of workable solutions now (which is what they do). And don’t ask me to work with subpar ide’s to get average interactions/simulations elearning while you play catchup.

  7. Raju Bitter says:

    5 years of RIA development and discussions have taught me one thing: don’t write Flash off to quickly, and value it for what it’s good at. I’ve been asking for an open source version of Flash many years ago, and have to admit that projects like Gnash don’t seem to be getting anywhere (yes, I haven’t been working on it, don’t have the time or enough money to do it).
    Seeing how Silverlight and JavaFX – technologies launched by companies much larger than Adobe – have failed to gain similar traction in the RIA space makes me respect Adobe’s success. Adobe – with the Flex product line, AIR, the creative suites and products like Catalyst – proves again that the company understands how to deliver quality products increasing productivity in software projects. And Adobe clearly has adopted the open source idea – which makes me a lot more comfortable using Adobe products.

  8. John Dowdell says:

    Thanks for all the comments, folks! 🙂
    I’ve been on the run the past 36 hours, but have been thinking and thinking on Karl’s point. I was saying “copycat technologies don’t usually do well, and I want hypertext itself to be improved.” Karl came back with (well-meaning best-guess paraphrase) “but flash isnt open”.
    Brought me to realize there are two constituencies here: those who want to make content, and those who want to make tools.
    I’m not sure the toolmakers always “get” the creatives. In the real world of content development, Ajax variance is a cost, not a benefit. The current state of CSS is not a blessing, but a curse. Only a spec was delivered, not a capability.
    People publishing communications don’t want the extra costs of dealing with each and every proprietary implementation of a spec. Toolmaker rights may not stomp creative rights or consumer rights.
    “How can I publish a video?” *must* involve codecs, in a way that “How can our runtime have our own competitive VIDEO?” need not. I see much of the off-topic stuff in the WhatWG HTML5 process as coming from Apple and Google, and their Microsoftian need to shun dependencies in their audience’s rendering stack. A useless VIDEO tag makes Apple happy, and also makes the Mozillans happy, but for different reason. Doesn’t make content creators happy.
    Maybe I misunderstood you, Karl, but when you went straight for “re-implementer’s rights?” it took me awhile to comprehend. On my list of important questions, “Can I modify your sourcecode?” is way, way down there compared to “How can I communicate with people who want to hear me?”
    Agree, disagree, additional perspective…?
    tx, jd/adobe

  9. pthimon says:

    “How can I communicate with people who want to hear me?” and “Can I modify your sourcecode?” *are* intrinsically linked when considering the overall cost of what technologies to use.
    Whilst Flash undoubtably provides the best price/performance ratio *right now* (predictablility is good), that has to be weighed against the future cost of using a runtime that is not “open”.
    [jd sez: I agree longevity risks are a factor to consider (see Platforms: How wide? How deep? How chunky? How durable?), but I don’t think it’s the only concern to have. And as today’s IE8 release shows, existing content can be affected by any runtime release. ]
    By “open” I mean the ability to easily port to new devices and architectures (i.e., without the need for reverse engineering or licensing restrictions), because Adobe can not always be relied on to fund the porting to the devices a content creater may be interested in deploying to (case in point: the state of 64bit GNU/Linux before Adobe invested in seriously supporting that architecture).
    If developers can be convinced that CANVAS/VIDEO provides better long-term assurances that their content will be available to the widest possible audience then perhaps that is the technology that they will invest their time in learning/creating/deploying/evangalising.
    Also, I agree with your comments about browsers integrating better with plugins – however, I would go further, and taken to its logical conclusion, that means all the rendering engines for a browser should be “pluggable”, i.e. I can use Opera’s html renderer in Firefox’s browser UI with Chrome’s javascript engine and Flash’s multimedia renderer for CANVAS content. Then I can deploy CANVAS now with the assurance that I can still use the same content with a different renderer further down the line (that would mean standardising the interface between the content specification and the underlying renderer which hopefully can be done, e.g. with Flash being the ‘standard’ implementation for CANVAS so that doesn’t lead us back to the same problems of unpredictability of the renderer like we have with CSS now…).

  10. Laura says:

    Would love to see a Flash versus Canvas accessibility comparison.
    [jd sez: Screenreader support? or maybe text-to-speech buttressed by color modes, motor demands, etc? Biggest difference still seems to be in authoring choices and attention-to-detail…? ]