What can SVG learn from Flash?

Regular readers of my blog know that I also worked on the Macromedia Flash Professional authoring tool and the Adobe Flash Player for many years. I learned a great deal about the design of ubiquitous platforms, and the limitations of single-vendor implementations. At a recent meeting with the W3C SVG working group, I shared some of my thoughts on how Flash was able to reach critical mass across the Web, and how SVG can leverage those lessons for the future.

Basically, it boils down to 3 principles:
1. Flash offered expressive design-fidelity across all user agents.
2. Flash authoring was superior to SVG authoring tools for producing content that adheres to principle # 1.
3. Most Flash content is self-contained and atomic in a packaged file format that helped preserve design-fidelity in # 1.

I shared some feedback regarding what I hear from Firefox users about SVG. I also shared what I never hear from Firefox users: “We need more SVG features.”

As the working group ponders new SVG specifications for review, the main gripe I hear from users is the lack of interoperability for the current feature set. That is, I don’t get requests for a new DOM or fancy gradient meshes, I get bugs about basic rendering differences across browsers. As a result, I’ve directed our SVG investment towards these paper cuts that make authors distrust SVG for complex designs. I can see why it’s more tempting to focus on new feature specifications, but adoption is hampered by the legacy of interoperability (or lack thereof.) I’d like to see the group organize around fixing these bugs across all browsers in a coordinated fashion, eg. in a hackathon or bug bash at a future multi-browser face-to-face meeting.

I also talked about how SVG could be a very expressive authoring source format for a modern implementation that is more focused on pixel-fidelity. Unfortunately, I didn’t get a lot of support for that idea from other browser vendors, as the desire to compete for the best implementation seemed to outweigh the benefits of dependable runtime characteristics. I’m really surprised that SVG hasn’t stepped in to replace Flash for more use cases, and I’m quite certain that the 3 principles I mentioned above are the reason why. I do hope that authoring tool vendors step in and help drive the state of the art here. It’s one thing for browser vendors to offer competing implementations, but the lack of strong authoring systems makes it hard to define what it means to be correct.

I spoke with a few people about how the packaged SWF format was an advantage for Flash because it was easy to have this content move across the internet in a viral fashion without losing any of the assets. Flash games, for example, are commonly hosted on multiple servers (often unknown to the original publisher) and still retain all the graphics and logic within the SWF file. The W3C application package proposal is something we could implement as a format that lets HTML/SVG content traverse networks intact. It’s not hard for such HTML/SVG applications to be made up of hundreds of individual assets that are easy to lose track of. Having a packaged format with clear semantics and security rules (eg. iframe in a zip) could be a really good feature for the modern web.

What else are we missing for SVG to gain critical mass? Post a reply below or find me on twitter!

16 thoughts on “What can SVG learn from Flash?

  1. It’d be great if we could just allow at least the audio tag to work within SVG SMIL (it’s in the spec) so sound effects can be synchronised with simple declarative animation events, without the need for javascript.

  2. I think your points are exactly right (we shouldn’t add or subtract anything to or from them), and we need to make progress on them.

    The lack of a proper packaged format for HTML has frustrated me for over 15 years. IE has had the relatively decent .mht format for a very long time. Let’s just get on with it!

      • It’s quite a leap to make authors have to write their own codec and scene graph as the Shumway team did. Shumway also has to jump through hoops to maintain security. Ideally, the existing constructs for HTML, CSS, and SVG can be used but within a container format that has consistent security origin rules.

  3. I think performant animations and a sane API are holding back SVG adoption and tooling.
    Even mozilla’s Shumway is using canvas.

    • I think the requirements for faithfully emulating an existing platform (Shumway) are different from the requirements for authoring and deploying ads and other animations. Performant animations and a saner API would not make SVG significantly more attractive as a target for compiling Flash to.

      • I’m not thinking about Flash.
        Performant animations and a saner API would drive tool support. This would increase the number of authors to create SVG.
        Most authors don’t care about the format or how clean the markup is; they just want to have things work and work consistently.

          • Shumway is using canvas because it has a saner API and much better performance.
            I’m sure there’s a blog post somewhere where the shumway engineers explain their decision.

    • HTTP/2 push solves a performance problem. Jet is talking about an integrity problem: making it “easy to have this content move across the internet in a viral fashion without losing any of the assets”. HTTP/2 doesn’t address that at all.

  4. Jet, I think the other people at the table just felt that the basis for a “expressive authoring source format … that is more focused on pixel-fidelity” should be canvas, not SVG. In other words, tools should compile rich source formats down to JS driving a canvas, and we should strive to improve the interoperability of canvas (perhaps by providing options that force more tightly-constrained rendering).

    Then I heard that Adobe already has a tool for compiling the Flash authoring format to canvas. I’d love to hear more about that, and how we can help make it work better!

  5. Is there a cross-browser test suite for SVG?

    The various acid tests have been criticised for exactly what they tested, but there’s no doubt that they encouraged browser vendors to all focus on correctly implementing, because there was suddenly an easy way they could be compared (either as a rendered image and/or a number).

  6. SVG is focused on creating images and animations. Can you imagine if image and video formats weren’t focused on fidelity on different browsers?
    JPGs in IE had a bluish tinge and H264 videos in Chrome run at 1.25x speed (because people are busy). Even if they were “technically” the best, nobody would use those formats because they couldn’t be relied upon.
    The next Homestarrunner-like web comic won’t use SVG, even if it’s as full-featured as Flash, because it can’t be relied upon (heck, the current homestarrunner wouldn’t switch over to it even if good tools were in place).

  7. My main issue with SVG is that changes to the scene need to be parsed from text strings and this results in poor performance. For example, animating a curve should mean setting control point values, not concatenating path strings that then need to be parsed by the browser to regenerate the curves. Anything that addresses this inherent structural deficiency would be a huge boon.

Leave a Reply to Rik Cabanier Cancel reply

Your email address will not be published. Required fields are marked *