Making the case for HTML5 support in the Flash Player

Earlier this week I got inspired seeing this presentation on HTML5. I’m a strong advocate of moving towards this standard and with browsers increasingly supporting it, makes it very attractive to start to learn and implement where possible.

Contrary to what I’m seeing various tech blogs claim, HTML5 is in my opinion not a replacement to Flash. It will no doubt take over some features for which we used to have to rely on the Flash Player to implement — and that is a good thing — but there are still a lot of uses cases where it makes sense to use Flash. Not just that, we can leverage both technologies for what they do best (just as we do now).

After Serge Jespers’ blog post this morning and a brief discussion on Twitter I thought I’d blog what I think would be a good move for the Flash Player, adding HTML5 support through an embedded webkit engine.

Adobe AIR has this feature and allows rendered HTML to be integrated completely in the DisplayList and treated as any other visual element including filters, transformations etc. Script bridging allows Javascript to call ActionScript and vice versa.

Why would you do this?

  • Flash Player has limited HTML support
  • Certain popular and legacy browsers do not support HTML5
  • It would give a consistent set of HTML5 supported features across browsers
  • Deep integration of HTML5 content within the Flash DisplayList
  • Flash Player would become a catalyst for HTML5

What are the difficulties?

  • Flash Player filesize
    The Flash Player team is always very concious about download size of the player — an embedded HTML engine would obviously add significant file size. To address this I’d propose an approach similar to the cross-domain Flex framework caching, where they would only download and cache when first needed.
  • Plugins shouldn’t render HTML
    I certainly agree with that in principle and that would also be what you would typically do. In certain situations though it is a pragmatic solution and no different to what Google does with Google Chrome Frame. If you have an HTML5 capable browser and do not need to deep integration with Flash features this wouldn’t be used.

Just to be clear, I’m not suggesting the Flash Player to become the standard delivery mechanism for HTML5 content. I see it used in one two situations:

  1. As a reliable fallback mechanism for browsers that don’t support HTML5
  2. In situations where you want to integrate HTML5 content in the Flash DisplayList (visual effects etc.)

Taking this even further you could potentially even see Alchemy C/C++ code cross-compiled and applied to HTML5 content hosted through the Flash Player.

Whether or not this is technically feasible or likely to happen, I think it is something worth looking at.



20 thoughts on “Making the case for HTML5 support in the Flash Player

  1. V1 says:

    If you run chrome or safari.. You will actually be doing:

    Webkit > Flash > Webkit.. to load the contents.

    A better solution would be that Flash is able to interact with the DOM, without external interfaces instead of providing a complete DOM browser.

  2. Peter says:

    If you run Chrome or Safari there wouldn’t necessarily be a huge use case for this feature of course 😉

    I agree that direct DOM integration would be fantastic, though that doesn’t have the added advantage of serving as an HTML5 fallback mechanism on browsers that don’t support it and doesn’t give a consistent set of features.

  3. Lee Probert says:

    Can someone explain why it is too difficult for Adobe to export to HTML5 from Flash? Surely this is the direction they should be heading.

  4. Peter says:

    I’d love to see that happen Lee, lets be honest though for now HTML5 isn’t something you can reliably deploy cross browser and cross platform to 90% of your audience.

  5. *cough* Postloading code as plugin is nice for every maleware distributor.

  6. If it hasn’t been done already, I suggest requesting this at You got my vote :).

  7. Meinte says:


    In retrospect, you could get cool visual feedback patterns if you would allow the webkit implementation within the player to play flash itself and then:!

    make the flash app show it’s own page which will show the flash app, which will show the page, which will show the flash app. woohooo 🙂

  8. Stan Vassilev says:

    Adobe supports now dozens of desktop and power-starved mobile platforms. In that situation, them casually throwing in an entire browser engine would be an excellent display of humor.

    You remember a decade ago when Macromedia threw in casually a 3D engine in Shockwave. That didn’t save it.

    On a serious note, big chunks of HTML, CSS and SVG have been implemented with pure AS3 before. Flash 10 has the right APIs for implementing that.

    Flash is a platform for developers to build features on, it’s not a feature/component shop on its own. AIR’s WebKit is just an artifact of Adobe’s attempt to gain quick adoption among web developers. In the browser, we always had the HTML/CSS/JS stack, and so there’s no need for another.

    PS: Certain popular and legacy browsers have gained some upgrades:

  9. matthewfabb says:

    @Lee, Adobe has demoed an Flash to Dreamweaver export, which displays in the canvas tag (search for it on YouTube). However, it only works for basic animations. Porting ActionScript to JavaScript, while not impossible would be a pretty big technical challenge that would require a lot of resources. Of course since HTML5 doesn’t support all features found in Flash, certain things would have to be disabled.

    As for the topic at hand, I think the file size would likely stop this from happening. To render anything on the page, the user would have to wait for a 5 to 10 meg download (I have no idea how big the WebKit engine is) before rendering just plain HTML content. Then I imagine there would be the occasional security updates, making it hard to get penetration numbers up of people even using the same version of WebKit + Flash.

  10. Peter says:


    “I think the file size would likely stop this from happening.”

    That is where the caching mechanism comes in, as with the Flex framework caching feature it would only need to be downloaded the first time and can be used cross domain from that point onwards whenever it gets referenced.

  11. Benny says:

    Imagine you go to a site and first you have to wait a few secs to load the webkit engine, then the Flex SWZ then the TLF SWZ then the site itself.

    Many users will click away when the site isn’t available within a few (<5) seconds. On the otherhand when downloading software (including plug-ins) they do expect this process to take some time.

    IMHO even the SWZ files should be pre-installed WITH the installation of the FlashPlayer so that only a minimum of users have to download it on demand.

    That said native HTML5 support by the FlashPlayer would be something I would welcome.

  12. DannyT says:

    I think a lot of people are misunderstanding this.

    This is not a suggestion to just use Flash solely for rending HTML5, this is an approach to reaching wide-spread html5 adoption in a very short space of time whilst offering reliable cross browser compatibility.

    with the rate of flash player deployment, within 10 months you could have a HTML5 site running in IE6 identically to how it does on the latest version of safari for some 90%+ of web users.

    The Flash version of your site would only be used where HTML5 (or the parts of it you use) isn’t fully supported in the users browser.

    I fail to see the disadvantage of this really other than a slightly increased download size.

    • devu says:

      Thumbs up DannyT.

      And I will be always flame on any Flash developer who trying to overblown the beauty of AVM. Give another one argument to people against flash platform.

  13. Joel Fiser says:

    I think this idea shows a lack of understanding of the true value of plugins. That being cross-browser and cross-platform compatibility.

    HTML5, like all web “standards” will ~never~ be implemented consistently across browsers and platforms. There will always be business reasons that browser A will implement HTML5 differently from browser B. That’s where plugins like Flash come in – to provide that consistency.

    So your idea, then is to add HTML5 to the plugin? Why? What value does that offer? Flash can do way more than HTML5, so just use Flash for whatever you’re trying to accomplish with HTML5.

    Look, I know it’s tough being a Flasher these days. We’re besieged on all sides. But that doesn’t mean we’re wrong. If Flash has everything and more than HTML5 – why the hell would you ~ever~ use HTML5 other than to appease the so-called “standards” zealots?

  14. TK says:

    We’ve needed this for a long time. Flash applications need to be able to run ads, and this would enable us to do that properly.

  15. Adrian Parr says:

    “I’d love to see that happen Lee, lets be honest though for now HTML5 isn’t something you can reliably deploy cross browser and cross platform to 90% of your audience.”

    I think in the long-term (next 10 yrs) this is the direction they should be heading in.

  16. Joel Fiser says:

    I’m really trying to understand this…
    What are the features of HTML5 that are not present in Flash?

    Let’s say HTML5 was available on all browsers right now… Can you give me an example of where it would be advantageous to use HTML5 over Flash?

    Am I missing something?

  17. John Dowdell says:

    I haven’t run through all the comments, sorry, but another path to the same goal may be better integration between browsers and their extensions… Google and Mozilla are already working with Adobe on such improved integration:

    (Looks like WebKit nightlies are much larger than Flash Player… search query “download webkit mb” range greatly but are often a factor of ten!)


  18. leef says:

    I don’t see why you would want to export HTML5 from Flash source as some people are asking about, or why you would want HTML5 integrated into the FlashPlayer. I imagine it would a nightmare for Adobe to maintain. Besides, aren’t all the browsers that will support 10.1 also support HTML5?

  19. HTML support has been requested nearly 3 years ago ( I get the impression that Adobe is specialized in focusing on the wrong issues first! And if they, after years, finally implement a much needed requirement (eg the global error handler) then they market it as the next big thing after sliced bread… Very frustrating!

Comments are closed.

%d bloggers like this: