-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Continue to improve SMIL as the main animation method of SVG #63
Comments
CSS's animation model is also a declarative animation format. The differences are relatively minimal, and are quickly approaching zero as we merge the two worlds more. There is no significant difference between an |
It's good to hear of SVG use outside of the browser world. While SMIL is no longer in SVG 2, it remains in SVG 1.1 SE and user agents that support that version continue to support SMIL animation. Chrome has deprecated SMIL and have said they would like to remove it one day, but while it is being used they can't. If usage drops enough then it becomes a possibility for them. |
It's worth reading https://www.w3.org/wiki/SVG/Animation if you haven't already. |
CSS is not nearly enough to create complex animations. This is why you HAVE to use javascript to match the level of animation that SMIL already offer. It is also very hard to use CSS to interact with SVG. You cannot even include SVG definitions in CSS style sheets files, if not as a base64 blob. The converse is also true. You cannot use CSS to animate SVG from inside the SVG file. It is also impossible to use CSS on mobile apps, while SVG animated Icons with SMIL are used by many iOS and Android applications. If CSS will become one day powerful as SMIL and part of the SVG syntax so that it can be integrated inside the SVG image file, then it will become a possible substitute for SMIL. But until then, SMIL is the best format for animations and should be the default for SVG. |
As I said, there are still some differences between the two animation models, but they're quickly narrowing to zero. (SMIL lacks some functionality that CSS provides as well; neither is a subset of the other.)
Yes you can. What makes you think you can't?
This is a weakness of some of the tools rendering SVG, not an intrinsic weakness of the platform.
As Nikos said, Chrome has deprecated SMIL and plans to one day remove it, and IE has never implemented it. Features that are not usable cross-platform and don't have a path to ever being supported cross-platform aren't useful to spec; they're an attractive nuisance that encourages people to write browser-specific code. While SVG is used outside of the browser sphere, its usage is roughly similar to HTML outside of the browser sphere - relatively insignificant in usage numbers and often plagued by incompatibilites. We intentionally focus on browsers because it represents the vast majority of SVG usage. |
@nikosandronikos I've read the linked documentation, and I know for sure that Web Animations will not be backward compatible with SMIL. Many companies started developing new SVG animation applications and tools, all exporting in SVG+SMIL. Those applications are soon to be announced, and their impact will be huge. For the first time it would be possible for artists with no coding skills to easily create SVG animations usable in the IMG element. This will change the worldwide usage of SMIL from the current small percentage to a whopping 20% in a matter of few months. The web will be then inundated by free animated SMIL icons, buttons, background tiles, etc. They will become more common than animated gifs, because of the much smaller file size. I know this because I happen to work for one of such companies, and estimations have been made. Some experts on Web Animations have been consulted, like Eric Willigers from Google. He is the author of a SMIL polyfill that uses WebAnimations to reproduce SMIL: https://github.com/ericwilligers/svg-animation Yet he confirmed to us that WebAnimations are not able to reproduce all SMIL animations because of many differences in syntax and many limitations of the web animations model, like the lack of a calcMode="paced" mode. |
@tabatkins Are you saying that you can create an SVG animation like this: http://www.tbyrne.org/portfolio/smil/LoveDota.svg without using SMIL, and using just CSS inside the SVG file, with no javascript? How? |
|
Here are some examples of SMIL features missing from CSS:
|
@tabatkins You can today, not tomorrow, use Adobe Animate CC and the Flash2svg plugin ( https://github.com/TomByrne/Flash2Svg ) to export ANY flash animation in SMIL as a single .svg file, even an entire cartoon episode with audio (like this: http://www.tbyrne.org/portfolio/smil/LoveDota.svg ), usable everywhere without depending on browsers or javascript libraries. This is already heaven, the best you can ask to a vector format. All thanks to the power of SMIL. And yet you are going to drop everything and make SVG dependent on an external, less powerful format like CSS, made for the web and not for animations, with no way for artists to edit it without coding skills? Why? This is a choice that damages everybody, from artists, to developers to the svg standard itself, because it removes its best feature for no reason. |
@Emasoft I look forward to seeing those products. I hope they have the effect you describe. Was Eric referring to the implementation of Web Animations in Chrome? (it's still in progress) or the spec model? |
@nikosandronikos I checked his email again and he referred to the Chrome implementation lacking the paced mode. Here is the relevant passage from his email:
The differences are still huge and you cannot say that WebAnimations is backward compatible with SMIL. |
Hi, implementer of SMIL in Firefox and Web Animations / Animation Elements spec editor here. Regarding features:
This is achieved by having multiple animations the same as it is in SMIL (unless I'm missing something here?)
As in a per-repeat delay? How do you do this in SMIL? With
What do you mean by this?
Right. This is not there. It's true you need script for this, but I think one of the biggest advantages of using SMIL over script is that it works in non-scripted contexts. These attributes, however, typically don't work in non-scripted contexts--only scripted ones. If you're in a scripted context, then it seems reasonable to me to use javascript for these steps since it's much more flexible.
This is in Web Animations. It's called a composite operation and you can even specify it per-value (as opposed to per-animation) which let's you do things like SMIL's to-animation. We also intend to expose this to CSS in CSS Animations 2.
This is similar to the event-types above. Firefox never implemented wallclock-sync (I'm not sure if other browsers did), and accessKey has the same restrictions regarding not being available in non-scripted contexts. Likewise for event. I suspect that for repeat, many use cases can be covered with timing groups once we get to them.
This is not in CSS or Web Animations. It is possible to guarantee that animations start at the same time in CSS. You simply need to trigger them within the same animation frame. The Web Animations API provides more fine-grained control for synchronizing new animations with existing ones. But in general, syncbase timing is one of the most problematic areas of SMIL due to the cycles it creates which makes it impossible to seek in constant time. In Animation Elements I was proposing we simplify the model significantly to something more like a DAG.
As @nikosandronikos pointed out the web animations model does have an equivalent for All that said, recently I've been hearing more people expressing interest in doing something like Animation Elements, even amongst certain Chrome folks. I don't have the time to work on it at the moment, but if there is still interest once we've shipped Web Animations API, we could look into reviving it. It would basically be a slightly nicer version of SMIL which shaves off the messy parts, adds some missing parts, and is implemented on top of Web Animations (possibly using Web Components and Javascript only but shipped natively). |
@birtles Thank you for your detailed answer. You can find an in depth explanation of those lacking points of CSS here: https://github.com/webframes/smil2css/wiki/Limitations But I think that everybody is still missing the point here. You are talking about requiring "web components" and "javascript" to support basic SMlL features that artists already uses to make movies, cartoons, mobile UIs, videogames, animation layers in video editing and composing studios, etc. All those people trusted SVG because it was a standard vector format for graphics and animations. You can be a japanese artist working with an obscure software in Tokyo, and yet you can send your work to an animation studio in Los Angeles that uses another completely different software with no problems, all thanks to SVG and SMIL. You can ask your team of artist to create amazing animated buttons, icons and controls for your new mobile app, and they will work on iOS, Android, WinPhone, etc. with no problems. No need to write custom code, to use a browser or web components, and no need for javascript coders to become animation artists. It just works! STOP THINKING ABOUT SVG AS A WEB ONLY FORMAT. You are betraying all the people that trusted SVG as their file format. And you are damaging all the companies, like the one I work for, that are trying to make software applications for creating animation visually, exporting them as a SVG file, no strings attached. No one is using the native export mode of Adobe Animation CC, because it generate tons of bloatware: html files, javascript files, css files, many svg files... it is a mess. Everybody is using flash2svg plugin instead ( https://github.com/TomByrne/Flash2Svg ), because it exports a simple single SVG file (like this: http://www.tbyrne.org/portfolio/smil/LoveDota.svg ), that you can use everywhere. |
@Emasoft, because you work for a real company making money off of this, you may be able to provide insight into the cross-browser compatibility issue. How are you handling Internet Explorer and Edge? Without calling SVG a web-only format, we still need to consider the web when talking about SVG. One of the goals of this group is compatibility among implementations. |
@progers Currently, for the "export for the web" option, we are working with a prototype that uses Eric Willigers polyfill. But it is still incomplete and buggy, and this is why we asked the help of Eric. I'm not the one who is writing the exporter, but I can give him your email and tell him to contact you if you need something specific. |
@Emasoft Thanks for the link. I went through the items in the "Most Common" section and I believe all those things are possible in CSS. Let me know if I can help with any details. Regarding Web Components, that's just an implementation detail. I'm not suggesting SVG viewers would be required to offer Web Components support. However, a version of SMIL that can be implemented purely in terms of Web Components and Web Animations is more likely to get traction from browser vendors who already support those features (and are keen to remove native code for security reasons). Feel free to ignore that point. I can see your point about not wanting to use script when serializing animations. I'm not completely convinced that SMIL's sequencing primitives are what we really need, however. There are a lot of common cases they can't cover (e.g. a button that swells when you hover over it and shrinks using the same amount of time when you hover off it, including when you hover off mid-way through--something CSS transitions handles well). I think the timing group primitives might be more suitable. Some analysis here. |
@birtles Please, go trough the "less common" as well. Our exporter uses those SMIL features extensively, they are not less common at all. About the SMIL limitations: it would be much wiser to fix that in the next SMIL spec, instead of throwing it out of the window. It would need a very special kind of masochism to kill one of the best open animation format in existence for just that. |
@Emasoft Perhaps you could point Steve Vachon here instead. |
Done. |
Why is this thread been closed? This issue is not yet resolved. Please reopen this thread. |
@birtles |
Multiple CSS animations per element are not possible. However, the reuse of elements (via
Initial delay, not a repeating delay. CSS can do it, but the clock does not start
I forget, but here's some documentation on it. I haven't worked on smil2css in nearly 2 years. I did document that it was technically possible, however.
I think @Emasoft's point regarding this not being available is that SMIL can achieve this functionality with JavaScript disabled. That can be pretty important for marketing. |
I don't fully understand why SMIL is being removed, by the way. Why not rewire it to simply provide an interface for Web Animations? |
The official plan of the CSS & SVG working groups is that SMIL as used in SVG should be redefined to use Web Animations. That way, implementers can optimize a single animations model, but authors could use any of 3 interfaces to access it: markup elements, CSS keyframes, or the new JS API. The Web Animations spec was designed with this harmonization in mind, and fully supports all SMIL features that had ever been reliably implemented, including some that aren't supported in the CSS animation syntax. The new SVG Animations spec will complete the "re-wiring", re-defining the SVG animation elements based on the common model. So, to address @Emasoft's original request: As mentioned in the wiki article linked by @nikosandronikos, these animation elements will technically no longer be "SMIL animation", but they will look much the same from an SVG perspective. Support for animation elements, just like support for CSS animations, will be judged separately from support for core SVG 2 features. The Working Group has discussed this multiple times in the past year, and that debate is not going to be re-opened. That said, everyone's time is finite. Given that major implementers are supportive of the Web Animations JS API and not of the markup approach, Brian @birtles' has been devoting his effort accordingly. Anyone who is eager to see continued work on the SVG Animations spec is encouraged to read that spec (and the Web Animations spec it is based on) & to file specific bug reports if you find issues. You can also let SVG implementers know that this feature is important to you. The best way to do that is to continue to use it (with JavaScript polyfills where necessary for web compatibility). If you are using animation elements in software and content that are not visible to browsers on the open web, you'll need to be more pro-active about ensuring bug reports are filed, both with implementers and with us if the spec is not clear. If your company depends on this spec, one option is to become a W3C member and contribute directly to its development. The Working Group has not deprecated animation elements, just moved them to a separate specification. Even if they are not well implemented in web browsers, they can still be used in closed environments such as native apps or the other situations @Emasoft mentioned. |
In simpler words, SMIL is not gone, it's just been renamed. The browser implementation situation still may not improve, too. |
@stevenvachon Thank you for joining! You put the finger right on the spot! The weak point of this SMIL affair is that it would cost nothing to rewire the current SMIL code into Web Animations commands, if they are so similar. So why breaking compatibility with all SMIL animations and with all applications that export in SMIL already out there or in development? |
@stevenvachon Could you explain what you mean by:
You can have a list of animations, e.g. |
@birtles You just wrote:
So you are now talking about a specification that does't exist yet (I see only a very incomplete draft here: https://drafts.csswg.org/css-animations-2/ ), maybe partially prototyped in Chrome, and not about the current CSS specification then? |
@birtles for mismatching It's important to note that even with all things moved to CSS, it does not accurately provide an alternative to SMIL for complex animations such as cartoons where synchronization is critical. As said earlier, this is due to when the clock starts. I hope that "SVG Animations" follows SMIL in this regard, and should if aiming for backwards compatibility. |
Yes, syncing animations together explicitly is handled in Web Animations through grouping, and it's reasonably likely that pure-CSS animations will gain this ability too. |
Can somebody answer my question? Is the new SVG Animations specification guaranteed to be BACKWARD COMPATIBLE with SMIL? Or there is a risk that it will break compatibility? https://svgwg.org/specs/animations/ Because of the growing demand for SVG animations the company I work for has invested money in the development of a new professional animation editor for SVG using SMIL. We need to know if you are really going to break compatibility with something that works so well. Can we get an official answer? Can you at least tell if the compatibility break will happen just for the web version of SVG, or for the general version of SVG too? SVG SMIL is widely used on mobile applications. Here is an example usage by the popular mobile app for iOS and Android VIBER (100 millions users according to Similarweb): http://www.tbyrne.org/viber-animated-svgs I invite you to take a look at those beautiful SMIL animations and tell us if and why you are going to deprecate them. |
Web Animations is currently mostly compatible with the feature-set of SMIL, and totally compatible with the feature-set of CSS Animations. We have plans in level 2 to add more capabilities to WA to fill in most of the remaining holes. There are a few things we currently intend not to cover, like syncbase timing.
Internet Explorer/Edge (~1/4 of the worlds desktop users, iirc) does not support SMIL, and does not intend to. Chrome (~1/2 of the world's users overall, iirc) has explicitly deprecated SMIL, and is attempting to remove it. Its usage is still currently higher than our removal-theshold rules allow, but the usage % recently dropped significantly when YouTube stopped using it for their play/pause button, and we hope through continued evangelism to get it down low enough that we can remove it. Betting anything on SMIL support is likely not a good idea. You're missing out on a good chunk of today's desktop users, and will likely lose another huge chunk in the near-to-medium future.
There is no such distinction. |
@tabatkins Mostly? In other words SVG 2 is going to break backward compatibility with SMIL?!! Why are you killing something that works? Don't tell me that it is because of small adoption, because I just cited you an app with a 100 Millions user base that uses SMIL animated emoticons every day. And that is just one example of many more. So I don't believe such story about usage, because it is simply not true. Something else must be at work here, so please tell me. You don't kill something so good just when it is starting to gaining momentum without a serious reason. You risk to lose all credibility. You created a standard vector image format that people embraced and trusted. If you betray such trust, developers like us are not going to invest in developing graphic tools for your standards anymore. Do you understand this? Do you know a single animation software exporting CSS vector animations? I don't. And I can tell you that they will never exists. Because CSS is not a vector animation format, it's a styling markup for web pages. Nobody in the graphic world is going to take it seriously. It is like asking Adobe to stop supporting PNG for bitmaps, and exporting images defined pixel by pixel in CSS. It will never happen. You are doomed to other 20 years of lack of graphic tools for the web. Only this time it is not because of Microsoft, but because of Google. So I officially make a last proposal for a change of plans: that the Web Animations specifications should be changed from "mostly backward compatible with SMIL" to "fully backward compatible with SMIL". Please at least discuss it before deciding about it. It is in all best interests. P.S. I also inform you that I'm going to write an article about the official SvgWG answer, to gain the attention of the community on this development that has serious consequences for the investments in the SVG format. I wrote about SVG in the past with enthusiasm ( https://medium.com/@fmuaddib/the-following-are-the-possible-ways-to-create-professional-animations-in-svg-9d4caca5f4ec ). |
Because it doesn't work. The purpose of a web specification is to help drive interoperability, so pages work the same on all devices eventually. If a major player publicly refuses to implement something, and another major player publicly deprecates it and announces plans to eventually remove it, then you're guaranteed that feature will never be interoperable in any reasonable expected future. This is where SMIL is. As speccing it can't make it interoperable, there's no sense in speccing it. So we remove it instead, and focus efforts on things that are interoperable across the web (or that we expect to be, as implementations catch up). Doing anything else is just writing extremely boring fiction.
We've discussed this at length several times in the past. This conversation does not introduce any new information that would cause the decision to be revisited.
I'm an SVGWG member, and am representing the WG opinion here to the best of my knowledge. |
I think @tabatkins has fairly accurately covered the situation. An important point about the SVG Animations specification. That spec does still base SVG declarative animations on SMIL and it does apply to SVG 2 as well as SVG 1.1 SE. There's nothing stopping engines that support SVG 2 also supporting the SVG Animations specification. Regarding your article, personally, I think a useful article would be one that documents usage of SVG declarative animation in non public facing web contexts. You've made a lot of claims about SVG usage within various industry groups, and it would be good to these claims substantiated so we can understand them in more detail. |
Thank you all for your concern and your indulgence. It is a rare thing. |
@Emasoft Google can't kill XML/SVG even if it wants to. For example, Github has recently switched from icon fonts to SVG. Also, did Dart kill JS? Nope 😉 |
Interesting discussion. I am studying SVG animations and SMIL seems to me the easiest way ( in 2020 ) to animate SVG for the artists. Thank you. |
Lately the SVG WG expressed the intent to drop SMIL as the main animation method of the SVG format, and to start merging efforts with the CSS group for unifying the animation approach on CSS Animations and WebAnimations.
Doing so would be a sure mistake. CSS, web animations, or any other web standard should NOT be considered when developing the SVG format.
This because it is now clear that SVG has become the de facto standard for vector graphics in a variety of fields OUTSIDE THE WEB SPHERE.
Just a few examples:
The web is not the only focus for SVG anymore. SVG is now an independent and self sufficient vector file format, and it should not rely on external javascript libraries or applications specifications.
Having its own declarative animation format is what allows it to be so successful and independent from the limited scope of the web. SMIL is also very complete and very powerful, and universally regarded as the best animation language in existence.
Even web developers prefer not to have to manually animate SVG elements with javascript. Artists are best suited to do animations, not programmers. Javascript is also not useful for all graphic elements included as IMG elements in the html page, because for security reasons the image tag cannot run scripts or javascript. SMIL is the only safe and efficient way to have a vector animation file working in a web page as an Image element. And it is also much better for artists. No vector or animation artists that I know are proficient in javascript, so they are asking to provide them an SVG format that they can export including the animation defined as SMIL instead of having to pay a javascript programmer to manually code the animation in a script prone to errors and hard to debug.
Animations functionality that are not included in the SVG format itself and dependent of external CSS, javascript or a running browser, are doomed to fail, because they require a programmer to do a graphicians job (bad for both, and with awful results), and because it would never be an universal, independent graphic format usable on every platform, from the web to mobile apps.
Here is an example cartoon animation exported to SVG with the Flash2Svg plugin from Adobe Animate CC:
http://www.tbyrne.org/portfolio/smil/LoveDota.svg
All this thanks to SMIL.
The text was updated successfully, but these errors were encountered: