I've recently done quite a bit of work with SVGs, including those with animations. Some observations:
* Edge doesn't support SVG animation in the older engine, only the newer Chromium-based one.
* Until recently, Chrome had a massive memory leak with SVG animations that loop if left up for several hours.
* SVG animations often cause enough CPU load to spin up laptop fans.
* There is no SVG support in email, so using SVGs in an environment that has both web and emailed pieces can mean duplicate assets.
* For maximum styling control, SVGs must be inlined. You cannot modify most attributes via CSS if they're loaded as an image.
And one nit about the linked tool from this post, Motion.app is a bad application name choice for OS X. It conflicts with Apple's Motion.app, which more than a few designers are likely to have.
The performance issues are what prevented me from using SMIL. A project I was working on called for an SVG animation that we also had to move on scroll (don't ask...). The animation was choppy and definitely got the fans spinning.
Swapping that out for the equivalent CSS animation and everything was smooth as butter. It's obvious that SMIL performance is not as important to the browser makers than CSS animation performance.
I had the opposite experience a few years ago, where SMIL performed better than CSS animation but it likely varies depending on what is animated. Problem was only that certain browsers at the time (old Edge for ex.) didn't support it. Thankfully Chromium and FF continue to support it. It has its place and also has supported features CSS has only fairly recently begun to see equivalents for (eg: motion paths).
> For maximum styling control, SVGs must be inlined
This was a real sticking point for me since editing and version-controlling a standalone SVG file is easier. I've had success with using Javascript to inline SVGs: https://github.com/jonnyhaynes/inline-svg
> SVG animations often cause enough CPU load to spin up laptop fans.
Yeah I really don't know why the article claimed animated SVGs are performant. They aren't. SVGs are incredibly slow to render, and asking them to animate is murder as a result. There's no acceleration for them at all, entirely CPU-rendered (slow) and then needs to be uploaded to the GPU for the rest of the otherwise GPU-rendered or at least GPU-composited scene (also slow).
Trying to do any of this on mobile, with extremely high resolutions, is going to absolutely tank performance.
It surely doesn't help that SVG 2.0 is on a seemingly perpetual horizon for almost a decade now and nobody was willing to guarantee functionality everywhere. And SMIL certainly will not be in that one.
Animation being only the tip of the issues, the moment you rely on anything, that isn't a filled polygon with no stroke, SVG support and compability starts falling apart in the most unexpected places.
The SVG + CSS is really clumsy combination. The SVG exists outside web technologies as vector image format, where CSS would be horrible choice. The combination of overly verbose XML and inadequate CSS, each with its own idiosyncrasies creates too much mental overhead for developers. Looking at some online examples, I would hate to work on project that uses this combination.
There is also JS animation option which has many flaws. I guess it is impossible to accelerate on GPU, it forces imperative instead of declarative animation style and you have to execute someone's code in order to show graphics/animation.
I don't think SMIL (or even SVG) is perfect, but it is still the best option for open vector graphics standard. Maybe a much smaller subset would be something all mayor players could agree to support? The transpiler to shader language would be a good solution for performance issues.
> You cannot modify most attributes via CSS if they're loaded as an image.
You can't modify the attributes with CSS outside of the IMG, but CSS embedded in the SVG still works.
I use SVGator to create animated SVG and it exports an svg file with embedded animation via css animation / transform, they work great as <img src=".svg">
you can inline external SVG files with SVG injection. Works pretty well and almost feels like working with normal images. Here is an open source SVG injector: https://github.com/iconfu/svg-inject
> There is no SVG support in email, so using SVGs in an environment that has both web and emailed pieces can mean duplicate assets.
FWIW, Thunderbirds displays svg sent as attachments inline at the bottom.
Whatever you do, of course, do not break plaintext email. I only use plaintext emails.
* Edge doesn't support SVG animation in the older engine, only the newer Chromium-based one.
* Until recently, Chrome had a massive memory leak with SVG animations that loop if left up for several hours.
* SVG animations often cause enough CPU load to spin up laptop fans.
* There is no SVG support in email, so using SVGs in an environment that has both web and emailed pieces can mean duplicate assets.
* For maximum styling control, SVGs must be inlined. You cannot modify most attributes via CSS if they're loaded as an image.
And one nit about the linked tool from this post, Motion.app is a bad application name choice for OS X. It conflicts with Apple's Motion.app, which more than a few designers are likely to have.