Animated SVG vs. GIF(sarasoueidan.com)
sarasoueidan.com
Animated SVG vs. GIF
http://sarasoueidan.com/blog/svg-vs-gif/
67 comments
I wrote a self-contained svg application in 2009:
http://www.vandenoever.info/blog/2009/05/01/cubetest.svg
Then and now it works fine in chromium and firefox.
Edit: here is a link to background information on using SVG for complete applications: http://www.vandenoever.info/blog/2009/04/27/writing-applicat...
Edit: here is a link to background information on using SVG for complete applications: http://www.vandenoever.info/blog/2009/04/27/writing-applicat...
Well, SMIL does exactly that but has lost traction and has been deprecated in favor of CSS and JS animations. Support has actually been removed in Chrome or will be removed in the near future.
AFAIK you can include Javascript and CSS inside an SVG image, but it's common practise not to do that. I don't know why, but there's no reason not to do it.
http://stackoverflow.com/a/5381905
http://www.w3schools.com/svg/tryit.asp?filename=trysvg_rect2 (This is inline CSS, but it can have a separate style element as well.)
http://stackoverflow.com/a/5381905
http://www.w3schools.com/svg/tryit.asp?filename=trysvg_rect2 (This is inline CSS, but it can have a separate style element as well.)
JavaScript isn't executed if you use the SVG via `<img>` or CSS, so it's not useful in those contexts (you'd have to include via `<object>` or `<iframe>`).
So far as why it's not commonly used elsewhere, unless you've programatically constructed the whole image already, it's rather a pain to animate SVG. The markup spit out by authoring tools for any non-trivial image tends to lack the structure you'd want for animation. I suspect that's why we see JavaScript APIs like d3 used instead of embedded JS.
Authoring tool could spit out JS themselves, of course, but in all the contexts where JS executes you can basically substitute a full HTML document, and that will be more flexible and performant (SVG is not well optimized in most browsers, as the OP notes.)
So far as why it's not commonly used elsewhere, unless you've programatically constructed the whole image already, it's rather a pain to animate SVG. The markup spit out by authoring tools for any non-trivial image tends to lack the structure you'd want for animation. I suspect that's why we see JavaScript APIs like d3 used instead of embedded JS.
Authoring tool could spit out JS themselves, of course, but in all the contexts where JS executes you can basically substitute a full HTML document, and that will be more flexible and performant (SVG is not well optimized in most browsers, as the OP notes.)
SVG is so much easier to update than GIF. We used it on MyMoustache.net, were able to localize and change text on the fly, change colors, etc.
[deleted]
I'm quite sad the the animated PNG format never caught on. Not only does it have a technical edge over GIF (full alpha channel transparency, more color channels, etc.) but it also tends to have better compression/smaller file sizes. I think that if Google had implemented support for it in Chrome it likely would have caught on.
I agree. It would be nice to see a format like Sublime Text's pseudo animated GIFs [0] take off. It's not perfect because it requires JS + PNG + JSON and currently the python build scripts only work well on linux. If other tools started providing export functionality to this format then it could get more interesting. Historically, iterating on these ideas on the client has been a good way to get standards implemented in browsers.
[0] http://www.sublimetext.com/~jps/animated_gifs_the_hard_way.h...
[0] http://www.sublimetext.com/~jps/animated_gifs_the_hard_way.h...
In my experience apng is usually only neclectible smaller than gif a and a way bigger if not in the indexed colours mode.
[deleted]
Tooling is the big issue here – there are lots of ways to create animated gifs, but very few to create svg animations.
All the examples deal with programatically-created animations, but there's definitely a market for a tool to create Homestar Runner-type animations using SVG.
All the examples deal with programatically-created animations, but there's definitely a market for a tool to create Homestar Runner-type animations using SVG.
That market was Flash, which has an absolutely huge content base of now-aging vector animations and games. I'm still not sure what the general rationale was for flash support becoming uncool, technical or otherwise.
edit: I suppose it was widely used for web applications or even entire websites, which is now an obviously inappropriate use case, but I've still yet to see any new web technology properly replace it for polished vector-rendered animations or games.
edit: I suppose it was widely used for web applications or even entire websites, which is now an obviously inappropriate use case, but I've still yet to see any new web technology properly replace it for polished vector-rendered animations or games.
> I'm still not sure what the general rationale was for flash support becoming uncool, technical or otherwise.
Flash became a pseudo web-standard, and a closed one so. This meant Flash-support could only be implemented on devices and platforms Adobe decided to support.
And Adobe's history when it comes to fixing bugs, problems and providing adequate support for anything but their #1 platform (Windows) was appalling.
When Apple launched the iPhone, they decided that they didn't want their platform dependant on other's people code and limited to whatever effort Adobe would bother to put in.
At the time it was a ballsy move, as flash was surely king. In retrospect, I think it worked out (mostly) fine and I'm glad they were willing to foot the risk.
I say "mostly", because with Flash going away, people have been asking for the open HTML-standard to include closed elements which they earlier would typically do in Flash: DRM and friends.
The result is that the open HTML standard is no longer open and that open-source software can no longer fully implement a standards-comliant web-browser, meaning you can only get "working" browsers from the big guys like Apple, Google and Microsoft.
That's a terrible loss for the web and for the future.
Flash became a pseudo web-standard, and a closed one so. This meant Flash-support could only be implemented on devices and platforms Adobe decided to support.
And Adobe's history when it comes to fixing bugs, problems and providing adequate support for anything but their #1 platform (Windows) was appalling.
When Apple launched the iPhone, they decided that they didn't want their platform dependant on other's people code and limited to whatever effort Adobe would bother to put in.
At the time it was a ballsy move, as flash was surely king. In retrospect, I think it worked out (mostly) fine and I'm glad they were willing to foot the risk.
I say "mostly", because with Flash going away, people have been asking for the open HTML-standard to include closed elements which they earlier would typically do in Flash: DRM and friends.
The result is that the open HTML standard is no longer open and that open-source software can no longer fully implement a standards-comliant web-browser, meaning you can only get "working" browsers from the big guys like Apple, Google and Microsoft.
That's a terrible loss for the web and for the future.
Adobe never provided a usable non-dog-slow version of Flash for iPhone.
So Apple only had the choice between no Flash and a really bad version. Flash ran really slow on OSX compared to Windows, so it was unrealistic to expect Adobe to suddenly provide a good implementation of Flash for the iPhone. Adobe painted them into the corner by not properly supporting small platforms.
So Apple only had the choice between no Flash and a really bad version. Flash ran really slow on OSX compared to Windows, so it was unrealistic to expect Adobe to suddenly provide a good implementation of Flash for the iPhone. Adobe painted them into the corner by not properly supporting small platforms.
Flash became unpopular partly because the authoring tools were very expensive and closed-source. They were, however, usable by real animators. People could, and did, do cartoons, not just spinning triangles. The bandwidth required was very low.
Flash's approach to animation, with an object stream and a timeline stream, was a good one; display could start without reading the entire stream, something the SVG/CSS/Javascript mess can't do.
Shockwave was even more advanced, with full 3D. For a year, Shockwave even had the Havok physics engine in the player, allowing full 3D games with physics, but Adobe didn't keep up the payments and it had to be removed.
Flash's approach to animation, with an object stream and a timeline stream, was a good one; display could start without reading the entire stream, something the SVG/CSS/Javascript mess can't do.
Shockwave was even more advanced, with full 3D. For a year, Shockwave even had the Havok physics engine in the player, allowing full 3D games with physics, but Adobe didn't keep up the payments and it had to be removed.
I take it you didn’t read Steve Jobs’ Thoughts on Flash (2010)[0], then.
In short: Not a vendor-neutral standard nor an especially good standard, bad for security, bad for performance, bad for battery life, bad for touch, and promoting a lowest-common-denominator experience.
I’m not sure I agree with all those reasons, but the killing blow for Flash was that all those iOS and Android devices don’t run it.
[0] http://www.apple.com/hotnews/thoughts-on-flash/
In short: Not a vendor-neutral standard nor an especially good standard, bad for security, bad for performance, bad for battery life, bad for touch, and promoting a lowest-common-denominator experience.
I’m not sure I agree with all those reasons, but the killing blow for Flash was that all those iOS and Android devices don’t run it.
[0] http://www.apple.com/hotnews/thoughts-on-flash/
I was a big Flash designer back in the day. Now I use a tool that converts auto-magically to HTML5 and creates nice, compact files. That tool is.... Flash Creative Cloud! Yes, Flash the app, not the player. The latest version works very, very well as an HTML5 animator, and allows javascript code injection.
I always kind of ignored the Flash Creative Cloud download link when I was updating Adobe, but that's because I didn't know this. Thanks for the tip! :)
You can use Sketch app to create animated SVG https://medium.com/sketch-app-sources/svg-metamorphosis-a9d6...
"use sketch" is a very strong phrase for what was documented there.
What that shows is creating three different SVGs in sketch and then animating them using the Snap.svg JS library to animate them.
What that shows is creating three different SVGs in sketch and then animating them using the Snap.svg JS library to animate them.
as far as I know there is only one authoring tool which can export to animated svg (svg+smil) - Animatron [0]
disclaimer: I work there
[0] https://www.animatron.com
disclaimer: I work there
[0] https://www.animatron.com
SVG is a pretty solid image format.
The issue is... It supports the execution of javascript as part of its standard. So suddenly your image file, becomes an entire webpage. Not to mention its pretty trivial todo some write malicious things with SVGs.
The issue is... It supports the execution of javascript as part of its standard. So suddenly your image file, becomes an entire webpage. Not to mention its pretty trivial todo some write malicious things with SVGs.
One thing to keep note of is that SMIL is being deprecated by Chrome.
https://groups.google.com/a/chromium.org/forum/#!topic/blink...
https://groups.google.com/a/chromium.org/forum/#!topic/blink...
It's also not supported in IE or Edge. Which makes animated GIFs way more compatible across different browsers.
SMIL is unnecessary, as explained in the article - use CSS or JavaScript to animate.
Having a self-contained document-type is the cornerstone of sharing/remix culture. If you want people to be able to post your neat animated-SVG infographic to Facebook or Tumblr or Imgur or wherever—or to make some derivative of it with a meme plastered on top (and you probably do)—it needs to be able to be right-click-downloaded as a single file, edited as a single file, and then re-uploaded as a single file.
CSS and Javascript can be embedded.
Pity the "performance" bit didn't mention CPU time - slow cheap phones deal a lot better with animated GIF than SVG.
So do regular computers.
Know of any stats to back that up?
It's just plain obvious that decoding a gif into a frame buffer is simpler than merely parsing the xml. Not to speak of rendering the vectors and animating them.
For rending each pixel in the frame buffers has to be set at last once, for both. In the case of Gif a simple lookup is performed for each pixel. In the case of SVG quite complex algorithms are required. I also suspect that the gif decoding is much cache friendlier.
My statistic: The SVG animation stutters, the gif sutters less.
For rending each pixel in the frame buffers has to be set at last once, for both. In the case of Gif a simple lookup is performed for each pixel. In the case of SVG quite complex algorithms are required. I also suspect that the gif decoding is much cache friendlier.
My statistic: The SVG animation stutters, the gif sutters less.
I do a lot of testing on mobile and this hasn't been my experience at all. I have no major issues with GIF, but SVG is always 'retina resolution', typically smaller, and we can even make the contents of the SVG responsive in the same manner as the other elements on the page using CSS.
My experience has been that SVG, where you are able to use them (browser support requirements) have been a huge hassle-saver! Plus you still have the editable file in your codebase so anybody can pick up any tool and make non-destructive edits :)
My experience has been that SVG, where you are able to use them (browser support requirements) have been a huge hassle-saver! Plus you still have the editable file in your codebase so anybody can pick up any tool and make non-destructive edits :)
It's not obvious to me, since my historical experience has been that a lot of browsers have had very poor performance with GIFs as soon as you have a bunch on a page, or you do something special like add some transparency or layering. Meanwhile, for CSS animations Safari set the bar high with GPU acceleration in their first implementation.
I don't know much about SVG so it would be interesting to learn how the real situation is there rather than some hunch.
I don't know much about SVG so it would be interesting to learn how the real situation is there rather than some hunch.
Do you have a source to back up that statement? Even an iPhone 5S will just die when you open a couple mb-sized GIFs simultaneously, whereas vector animations will use the GPU.
Very resouce hungry though which translates to poor battery life. One such image on every web page and you would only be able to browse the web for an hour a day.
I have an application that generates html export for display in a browser. One of the requirements of the application is that it needs to be able to run on computers with no external network connection.
I recently had to add some auto-scrolling capability to the display to support projector display. Users need to be able to copy the html file to usb devices, and so it wasn't really in the cards to use external images for buttons, so I simply embedded svg images for the play and stop buttons.
It worked well.
I recently had to add some auto-scrolling capability to the display to support projector display. Users need to be able to copy the html file to usb devices, and so it wasn't really in the cards to use external images for buttons, so I simply embedded svg images for the play and stop buttons.
It worked well.
You could have used a data: URI
Can you give an example, or a link to an example?
- https://css-tricks.com/data-uris/
- http://caniuse.com/#feat=datauri
- https://www.ietf.org/rfc/rfc2397.txtInterestingly, you can embed SVG in a data URL as well.
It's kind of ironic that the SVG animations stutter a way more than the gifs on my i5 while the text advertises svg as smoother.
Reminds me of a text about typesetting. The author was surprised that newepaper publishers switched from PostScript to Bitmaps (so from Vector to pixel graphics). But Bitmaps are just a way simpler to handle and with bitmaps the worstcase is the average case.
Reminds me of a text about typesetting. The author was surprised that newepaper publishers switched from PostScript to Bitmaps (so from Vector to pixel graphics). But Bitmaps are just a way simpler to handle and with bitmaps the worstcase is the average case.
Which browser? I'm running an AMD A4 and the SVGs are much smoother.
A current firefox on a somewhat dated X220 Thinkpad with a i5 core.
The two big problems with SVG are:
It's unsafe because it can contain javascript. You can't just let users upload SVG files, you need to strip them. As far as I know there is no image hoster that supports SVGs and I know of no website that contains user-uploaded pictures that allows SVGs.
Then there's the issue that SVG is an extremely complex format. It's not a format that's optimized for rendering like jpg, png, gif, but one optimized for working on it like psd, xcf, raw. No browser supports all of SVG. You can animate SVGs without javascript with the <animate> tag, but Firefox doesn't support it. There's some weird features basically nobody supports, like defining fonts inside of SVG. There are many features that are made for editing SVGs by hand, but if you ever opened a SVG generated by a GUI program like Inkscape you know that nobody would ever want to do that. The path format on the other hand is optimized for space and isn't really human readable.
It's unsafe because it can contain javascript. You can't just let users upload SVG files, you need to strip them. As far as I know there is no image hoster that supports SVGs and I know of no website that contains user-uploaded pictures that allows SVGs.
Then there's the issue that SVG is an extremely complex format. It's not a format that's optimized for rendering like jpg, png, gif, but one optimized for working on it like psd, xcf, raw. No browser supports all of SVG. You can animate SVGs without javascript with the <animate> tag, but Firefox doesn't support it. There's some weird features basically nobody supports, like defining fonts inside of SVG. There are many features that are made for editing SVGs by hand, but if you ever opened a SVG generated by a GUI program like Inkscape you know that nobody would ever want to do that. The path format on the other hand is optimized for space and isn't really human readable.
SVG is in some way an advanced, editable version of PostScript, PDF's ancestor.
Any SVG inside of an <img> tag is as safe as any image format. The JS code won't run, any external resources linked to from inside the SVG won't be loaded, the :visited CSS style is disabled[1]…
For added security, you can even send an HTTP tag called Content-Security-Policy: default-src 'none'; img-src data:; style-src 'unsafe-inline' gives good results. That's what GitHub uses, by the way[2].
> It's not a format that's optimized for rendering like jpg
You could argue the same of jpg in a comparison between jpg and bmp.
You can animate SVGs even within an <img> tag with SMIL or CSS.
Sure, there are a lot of features, and you could argue that it makes SVG complex; but the SVG specification[3] is not that much bigger than the PNG specification[4], if at all. It is irrelevant anyway when edited through a program, as PNGs usually are.
[1]: https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_as_an_I...
[2]: https://github.com/atmos/camo/blob/master/server.coffee#L43
[3]: http://www.w3.org/TR/SVG11/
[4]: http://www.w3.org/TR/PNG/
Any SVG inside of an <img> tag is as safe as any image format. The JS code won't run, any external resources linked to from inside the SVG won't be loaded, the :visited CSS style is disabled[1]…
For added security, you can even send an HTTP tag called Content-Security-Policy: default-src 'none'; img-src data:; style-src 'unsafe-inline' gives good results. That's what GitHub uses, by the way[2].
> It's not a format that's optimized for rendering like jpg
You could argue the same of jpg in a comparison between jpg and bmp.
You can animate SVGs even within an <img> tag with SMIL or CSS.
Sure, there are a lot of features, and you could argue that it makes SVG complex; but the SVG specification[3] is not that much bigger than the PNG specification[4], if at all. It is irrelevant anyway when edited through a program, as PNGs usually are.
[1]: https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_as_an_I...
[2]: https://github.com/atmos/camo/blob/master/server.coffee#L43
[3]: http://www.w3.org/TR/SVG11/
[4]: http://www.w3.org/TR/PNG/
If you look at the pdf versions you will see that the png specification is shorter by a factor of 10.
SVG: 826 pages http://www.w3.org/TR/SVG/REC-SVG11-20110816.pdf
PNG: 81 pages http://www.w3.org/TR/REC-png.pdf
SVG: 826 pages http://www.w3.org/TR/SVG/REC-SVG11-20110816.pdf
PNG: 81 pages http://www.w3.org/TR/REC-png.pdf
> I know of no website that contains user-uploaded pictures that allows SVGs.
openclipart.org does exactly that. I don't know if they strip scripts or simply forbid files containing scripts.
openclipart.org does exactly that. I don't know if they strip scripts or simply forbid files containing scripts.
> I know of no website that contains user-uploaded pictures that allows SVGs
Wikipedia.
Wikipedia.
SVG is a complex format, but it's not that bad compared to other widely adopted standards. Just for comparison:
- SVG 1.1 - 826 pages (http://www.w3.org/TR/SVG/REC-SVG11-20110816.pdf)
- HTML 5 - 1156 pages (https://html.spec.whatwg.org/print.pdf)
- ODF 1.2 - 1217 pages (https://www.oasis-open.org/standards#opendocumentv1.2)
- PDF 1.7 - 1310 pages (http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdf...)
SVG 2 spec is even smaller because it removes sections that are either duplicating other W3C standards (filters, styling) or not implemented by all major vendors (animations, fonts, path APIs).
- SVG 1.1 - 826 pages (http://www.w3.org/TR/SVG/REC-SVG11-20110816.pdf)
- HTML 5 - 1156 pages (https://html.spec.whatwg.org/print.pdf)
- ODF 1.2 - 1217 pages (https://www.oasis-open.org/standards#opendocumentv1.2)
- PDF 1.7 - 1310 pages (http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdf...)
SVG 2 spec is even smaller because it removes sections that are either duplicating other W3C standards (filters, styling) or not implemented by all major vendors (animations, fonts, path APIs).
You forgot that it also requires XML and CSS. I'm surprised PDF is just marginally bigger, considering that it's carrying around lots of legacy stuff is so much more than just a vector graphics format.
Anyway. SVG is not or only partly competing with the formats you listed. It's actually a format that's supposed to be included in those formats you listed. It's competing with PNG 81 Pages (http://www.w3.org/TR/REC-png.pdf) or EPS 31 Pages (http://partners.adobe.com/public/developer/en/ps/5002.EPSF_S... which is kind of cheated though because it requires the ~800 page postscript specification, at least it doesn't need XML and CSS additionally)
Removing sections that are standardized somewhere else doesn't make a file format easier, especially if you want to implement it outside of a browser.
There's still tons of features in SVG that are probably not used or not really needed:
Mandating IEE 754 binary floating point coordinates, while representing them as decimals that are usually rounded to 0.001 or 0.0001. This causes rounding errors all the time. The 16.16 fixed point format used in ttf seems more sensible for this usecase.
Including (parts of) external SVGs with <use>. <use> doesn't seem to be supported in Safari, Firefox or Inkscape anyway.
<switch> to make an SVG render differently on computers with different locale.
ARIA (accessibility) support, what happened to a description of the image?
Commas as optional separators in paths, but only at certain locations and only at most one of them. There have been several bugs in programs using SVG concerning the parsing path strings that were related to white space.
Basic shapes that can just as easily can be constructed using <path>, especially the polygon and polyline.
The total absurdity that is <text>. Text usually isn't the main content of images, yet the chapter about text is the longest in the SVG specification, containing stuff like text flowing along a path. And all this without supporting multi-line text. Just use <path> instead, bitmap graphics also uses rasterized text. If fonts aren't installed it may cause overlapping, or it might not get rendered at all.
Anyway. SVG is not or only partly competing with the formats you listed. It's actually a format that's supposed to be included in those formats you listed. It's competing with PNG 81 Pages (http://www.w3.org/TR/REC-png.pdf) or EPS 31 Pages (http://partners.adobe.com/public/developer/en/ps/5002.EPSF_S... which is kind of cheated though because it requires the ~800 page postscript specification, at least it doesn't need XML and CSS additionally)
Removing sections that are standardized somewhere else doesn't make a file format easier, especially if you want to implement it outside of a browser.
There's still tons of features in SVG that are probably not used or not really needed:
Mandating IEE 754 binary floating point coordinates, while representing them as decimals that are usually rounded to 0.001 or 0.0001. This causes rounding errors all the time. The 16.16 fixed point format used in ttf seems more sensible for this usecase.
Including (parts of) external SVGs with <use>. <use> doesn't seem to be supported in Safari, Firefox or Inkscape anyway.
<switch> to make an SVG render differently on computers with different locale.
ARIA (accessibility) support, what happened to a description of the image?
Commas as optional separators in paths, but only at certain locations and only at most one of them. There have been several bugs in programs using SVG concerning the parsing path strings that were related to white space.
Basic shapes that can just as easily can be constructed using <path>, especially the polygon and polyline.
The total absurdity that is <text>. Text usually isn't the main content of images, yet the chapter about text is the longest in the SVG specification, containing stuff like text flowing along a path. And all this without supporting multi-line text. Just use <path> instead, bitmap graphics also uses rasterized text. If fonts aren't installed it may cause overlapping, or it might not get rendered at all.
XML dependence will become optional in SVG 2 and hopefully it will be deprecated in SVG 3. Chrome team is already considering switching to HTML parser no matter whether the SVG document uses XML or HTML serialization.
<use> elements with external references are tricky due to the same origin policy restrictions and various browser bugs, but referencing local IDs works just fine. Inkscape for example creates clones and symbol instances with <use> elements.
The most obscure part of the paths specification, i.e. the pathSegList interface, is gone in SVG 2. There were some plans to deprecate the "d" attribute and instead introduce a nicer function-based syntax such as data="move(10, 10) line(20, 20)", but AFAIK this idea has been dropped. Still, the path data grammar is clearly defined in the spec, I'm not sure why browser vendors don't follow it.
SVG 2 will support multi-line text and embedded WOFF fonts. This feature is important when you are authoring e.g. UI mockups or posters. Even low level drawing APIs such as canvas have the text primitive. If you express textual content with <path> instead of <text> element then it will not be editable and selectable, screenreaders won't recognize it and search engines won't index it.
<use> elements with external references are tricky due to the same origin policy restrictions and various browser bugs, but referencing local IDs works just fine. Inkscape for example creates clones and symbol instances with <use> elements.
The most obscure part of the paths specification, i.e. the pathSegList interface, is gone in SVG 2. There were some plans to deprecate the "d" attribute and instead introduce a nicer function-based syntax such as data="move(10, 10) line(20, 20)", but AFAIK this idea has been dropped. Still, the path data grammar is clearly defined in the spec, I'm not sure why browser vendors don't follow it.
SVG 2 will support multi-line text and embedded WOFF fonts. This feature is important when you are authoring e.g. UI mockups or posters. Even low level drawing APIs such as canvas have the text primitive. If you express textual content with <path> instead of <text> element then it will not be editable and selectable, screenreaders won't recognize it and search engines won't index it.
One is vector-based graphic, the other is raster-based. Completely different use-cases. APNG vs GIF is a better comparison.
I remember SVG being introduced way back when as the solution to some of our HTML problems, and only in recent times is it gaining some momentum.
That probably means that VRML will become a thing in 2020.
That probably means that VRML will become a thing in 2020.
I see Adobe tools mentioned, but what free (as in FOSS) tools exist to work with animated SVGs?
As well as snap.svg, you may want to take a look at Pablo (I wrote it). It is for SVG manipulation and includes some animation methods [1] that utilise CSS or JavaScript callbacks (also SMIL which is recently deprecated).
[1] http://pablojs.com/api/#Animation
[1] http://pablojs.com/api/#Animation
Inkscape + snap.svg should cover a lot.
Every time I tried SVGs over past years there was always some problem with them. They didn't work in one browser, required some different format in other. I hope it will work flawlessly in all browsers some day because it's really nice format.
[deleted]
This is all known stuff right. Its basically vector format VS bitmap format.
Browser support: do u haz it?
Yes, SVG appears widely supported. See http://caniuse.com/#search=svg
GIF is easily injectable, easy to update, which allows a nice, quick iterative update cycle. It's also compatible across the board and pretty future-proof at the moment.
SVG animations could work better by containing the code within the SVG file itself. Not sure how compatible this would be, but something to look into. http://stackoverflow.com/questions/5378559/including-javascr...