The State of SVG Animation(blogs.adobe.com)
blogs.adobe.com
The State of SVG Animation
http://blogs.adobe.com/dreamweaver/2015/06/the-state-of-svg-animation.html
4 comments
As somebody who spent a lot of time and effort to figure out how to do Flash-style complex animations fully in SVG SMIL including reversed time loops, hierarchical time modelling via easings and to make authoring available for free in an online animation tool, I am very sad to see abrupt Google's decision to deprecate SMIL in Chrome without having a full replacement available. SVG + CSS can be used only for simple things, SVG + JavaScript competes with canvas + JavaScript and more efficient geometry formats, and in addition in both cases the declarative approach is lost. The goal of having Web Animations to take place of SMIL makes sense, especially with advanced time modelling, however there are still many cases where the current proposal can't do what SMIL does and it would take some time until Web Animations will become usable in all browsers at the expected level for professional animation. SMIL has its share of problems but it was more-less working on all relevant mobile browsers. Now we are basically left with nothing that can do the job.
This is the crux: "The goal of having Web Animations to take place of SMIL makes sense..."
Web animations are the modern approach forward. They are actively being developed in all browsers and work in both html and css. You can start developing this today using the polyfill: https://github.com/web-animations/web-animations-js
Web animations are the modern approach forward. They are actively being developed in all browsers and work in both html and css. You can start developing this today using the polyfill: https://github.com/web-animations/web-animations-js
Obviously Web Animations look very good given they seem to solve the (IMO) worst weakness of SMIL - time manipulation. In SMIL to get the same effect you'd have to approximate local time by complex easings and cut/reverse parts of animation depending on the direction of local time. Web Animations took a much more reasonable approach (I was actually puzzled SMIL had such a flaw in its design).
However, as a producer of a professional animation tool I can't wait until Web Animations show up finally someday, but have to address the need expressed by customers that call for open vector animations working on all devices right now - and SMIL was the only one that could have address that. Now, there's nothing until web animations show up, and we can't be guaranteed that the final implementations will be anywhere near promised functionality.
Even just retaining SMIL in its current state would have been much better than just outright dropping it for any kind of continuity. We will obviously provide Web Animations as well, but with the deprecation of SMIL we lost a stop-gap declarative solution for majority of mobile devices, and frankly I don't understand such a haste in dropping it (just sustaining it in Chrome at its current state can't be very difficult)
However, as a producer of a professional animation tool I can't wait until Web Animations show up finally someday, but have to address the need expressed by customers that call for open vector animations working on all devices right now - and SMIL was the only one that could have address that. Now, there's nothing until web animations show up, and we can't be guaranteed that the final implementations will be anywhere near promised functionality.
Even just retaining SMIL in its current state would have been much better than just outright dropping it for any kind of continuity. We will obviously provide Web Animations as well, but with the deprecation of SMIL we lost a stop-gap declarative solution for majority of mobile devices, and frankly I don't understand such a haste in dropping it (just sustaining it in Chrome at its current state can't be very difficult)
Excellent points.
SMIL usage is high so it's just being deprecated in blink to get the word out, but not removed just yet. If you're planning to ship both web animations and SMIL, I hope we can get everything you need in web animations before SMIL is finally removed. If you have specific examples you can share, please do post on the smil blink-dev thread.
SMIL support is rough in the old android browser. I suspect using the web animations polyfill will be a safer path than trying to support the SMIL edge cases.
SMIL usage is high so it's just being deprecated in blink to get the word out, but not removed just yet. If you're planning to ship both web animations and SMIL, I hope we can get everything you need in web animations before SMIL is finally removed. If you have specific examples you can share, please do post on the smil blink-dev thread.
SMIL support is rough in the old android browser. I suspect using the web animations polyfill will be a safer path than trying to support the SMIL edge cases.
Absolutely agree. I've had some work designing some really creative ad banners using just SMIL, self contained animated banners, all vector so responsive and hi dpi that you can throw anywhere in an img tag with some basic interactivity and gzipped to boot was a fantastic solution. Expected that IE couldn't be arsed to support it but severely disappointed chrome is dropping it.
A very good article for anyone interested in SVGs!
TL;DR; There is 3 main ways to animate SVGs: SMIL, CSS, and JavaScript, but today you should go with the JS way.
To me, the most interesting section of the article was the : SMIL vs CSS vs JavaScript . The authors main points in that section are:
SMIL: The current and future state of browser support for SMIL is the main reason why I neither use it nor recommend using it anymore today. [...] I expect SMIL usage to drop even more in the future.
CSS: As for CSS, it can only animate so many SVG properties, not all of them
JS: This is why JavaScript is currently my go-to tool for animating SVG, and my library of choice is Greensock.
I think this CSS/JavaScript comparison is true for much more than SVG: For instance, before having good Flex CSS properties for your layout you would need to use Javascript to do the job for you. CSS is clean but less bleeding-edge than JS.
TL;DR; There is 3 main ways to animate SVGs: SMIL, CSS, and JavaScript, but today you should go with the JS way.
To me, the most interesting section of the article was the : SMIL vs CSS vs JavaScript . The authors main points in that section are:
SMIL: The current and future state of browser support for SMIL is the main reason why I neither use it nor recommend using it anymore today. [...] I expect SMIL usage to drop even more in the future.
CSS: As for CSS, it can only animate so many SVG properties, not all of them
JS: This is why JavaScript is currently my go-to tool for animating SVG, and my library of choice is Greensock.
I think this CSS/JavaScript comparison is true for much more than SVG: For instance, before having good Flex CSS properties for your layout you would need to use Javascript to do the job for you. CSS is clean but less bleeding-edge than JS.
Related: https://twitter.com/paul_irish/status/608360576243388417
Unfortunately the linked site is broken, but that GIF is pretty awesome.
Unfortunately the linked site is broken, but that GIF is pretty awesome.
Here's the correct link: http://tympanus.net/Development/CreativeGooeyEffects/ from https://twitter.com/paul_irish/status/608380499271290880
This is an excellent summary of the current state of things.
tl;dr: don't use SMIL.
Microsoft has (correctly, I think) publicly stated[1] that they do not intend to support SMIL/<animate>. It's best for our platform to double-down on the alternatives: javascript, css, and web animations. Dropping SMIL is painful but it's the only way to get to true interop and a consistent web platform.
[1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/5o0...
tl;dr: don't use SMIL.
Microsoft has (correctly, I think) publicly stated[1] that they do not intend to support SMIL/<animate>. It's best for our platform to double-down on the alternatives: javascript, css, and web animations. Dropping SMIL is painful but it's the only way to get to true interop and a consistent web platform.
[1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/5o0...
I am of the opinion that SMIL has been dropped prematurely - there is no real alternative for the time being, web animations aren't finalized nor supported yet, and just keeping SMIL in the current state without developing it any further would be still better than the other alternatives (CSS/JS).
SMIL does not work in IE and is fairly broken in old Android browsers. It's not a viable solution anywhere, today.
I'm sympathetic to hobbyists and SMIL enthusiasts who are losing out here, but removing SMIL isn't changing what common sites can deploy to users today.
I'm sympathetic to hobbyists and SMIL enthusiasts who are losing out here, but removing SMIL isn't changing what common sites can deploy to users today.
Actually SMIL is not that interesting per se, its importance stems from being the only open standard for professional grade declarative vector animations supported by most browsers right now, i.e. equivalent to Flash.
As it's going to be removed soon, we would have to wait until Web Animations are finalized and properly implemented everywhere. Frankly, figuring out all the details of both specs and implementation deficiencies in browsers for SMIL wasn't the nicest experience (WebKit/Gecko/Blink), however there was a way to get it working in all of them in a single manner, and get 1:1 quality comparing to Flash animation. How long would it take for Web Animations to get there? As someone who was a member of a committee for an unrelated automotive standard as well as working with committee members of an enterprise messaging standard, I know very well how easily given various political interests this could turn into a solution nobody really wanted.
SMIL and IE have a complicated history. On a vast majority of recent mobile devices SMIL is perfectly usable (until Google drops the axe) and there was a surge of interest wrt SMIL driven by the availability of retina/HiDPI (small-form) displays and the need to scale animations properly, and we have an indication that our tool supporting SMIL was causing some waves in the industry as well.
I am also not sure why you'd assume only hobbyists and enthusiasts care about SMIL. I personally was dragged into it by the fact nothing else was anywhere near it functionality wise and it had to be implemented, while I could imagine much better standards myself. It was a completely pragmatic, non-enthusiastic reasoning.
As it's going to be removed soon, we would have to wait until Web Animations are finalized and properly implemented everywhere. Frankly, figuring out all the details of both specs and implementation deficiencies in browsers for SMIL wasn't the nicest experience (WebKit/Gecko/Blink), however there was a way to get it working in all of them in a single manner, and get 1:1 quality comparing to Flash animation. How long would it take for Web Animations to get there? As someone who was a member of a committee for an unrelated automotive standard as well as working with committee members of an enterprise messaging standard, I know very well how easily given various political interests this could turn into a solution nobody really wanted.
SMIL and IE have a complicated history. On a vast majority of recent mobile devices SMIL is perfectly usable (until Google drops the axe) and there was a surge of interest wrt SMIL driven by the availability of retina/HiDPI (small-form) displays and the need to scale animations properly, and we have an indication that our tool supporting SMIL was causing some waves in the industry as well.
I am also not sure why you'd assume only hobbyists and enthusiasts care about SMIL. I personally was dragged into it by the fact nothing else was anywhere near it functionality wise and it had to be implemented, while I could imagine much better standards myself. It was a completely pragmatic, non-enthusiastic reasoning.
Old Android browsers will eventually disappear.
That leaves us with it just not being supported by Internet Explorer.
There is clearly more than just that driving this decision, because Chrome pushes ahead with plenty of things that IE is publicly opposed to. In fact, wasn't that Chrome's original reason for existing? To implement the web platform that Microsoft was unwilling to.
That leaves us with it just not being supported by Internet Explorer.
There is clearly more than just that driving this decision, because Chrome pushes ahead with plenty of things that IE is publicly opposed to. In fact, wasn't that Chrome's original reason for existing? To implement the web platform that Microsoft was unwilling to.