Continue to improve SMIL as the main animation method of SVG about svgwg

[stevenvachon]

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?

[stevenvachon]

• Unmatching repeatCount per display element: one powerful feature of SVG/SMIL is the ability to not only independently animate the properties of a single element, but also control the repetition of each of those properties. CSS does not have this kind of control.

This is achieved by having multiple animations the same as it is in SMIL (unless I'm missing something here?)

Multiple CSS animations per element are not possible. However, the reuse of elements (via <use>), each with a CSS animation and initial delay could work, though not consistently due to the following point.

• Repetitions with an initial delay

Initial delay, not a repeating delay. CSS can do it, but the clock does not start onload like SMIL does; instead, starting as the document streams. The result are animations that do not play out in expected synchronization.

• Interrupting non-discrete animations.

What do you mean by this?

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.

• Animation event attributes: onbegin,onend,onload,on repeat.
• Specific time values: accessKey, event, repeat and wallclock-sync time values.

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.

[stevenvachon]

In simpler words, SMIL is not gone, it's just been renamed. The browser implementation situation still may not improve, too.

[AndreaMonzini]

Interesting discussion.
What is the situation now?
SMIL seems to be supported in all major browsers:

https://caniuse.com/svg-smil

I am studying SVG animations and SMIL seems to me the easiest way ( in 2020 ) to animate SVG for the artists.
What about the SVG Animations ?

Thank you.

[AmeliaBR]

@stevenvachon

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:
SMIL-like animation elements will continue to be improved. Improvement will be based on the shared web animations model. However, this will not be the "main" method of animating SVG, but one of three equally valid approaches.

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.

[Emasoft]

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.

[Emasoft]

@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.

[Emasoft]

@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?

[Emasoft]

@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.
Nobody wants to drag the entire web behind when using, storing or sharing an animation file. It's not what a file format like SVG was made for. So please, keep SVG independent from the web as it is today. Do not broke what is working so well.

[stevenvachon]

@birtles for mismatching repeatCount values on a single <animate>, CSS would need to support multiple animations targeting the same property. animation-composition sounds like a good future solution if it becomes spec.

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.

[tabatkins]

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 <animate> element and a <style> element defining an animation.

[nikosandronikos]

It's good to hear of SVG use outside of the browser world.
The working group does tend to be browser focused. It would be great if you could expand on your examples with details of products and companies. Ideally we would like to have representatives from those groups within the SVG working group.

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.
Ideally, the Animations Elements specification will define SVG native declarative animation in terms of Web Animations. The Web Animations model is (or can be) backwards compatible with SMIL so this would help browser vendors who must implement CSS animations and SVG animations, and be suitable for use outside of the browser environment. It's important to realise Web Animations is more than just an API, it's a unifying model for animation that is compatible with SMIL, CSS Animations, and CSS Transitions.
There is definitely a trend towards animating SVG with CSS animations rather than SVG elements, but that's driven by the market. If SVG native declarative animation is important, then we need the commercial entities and open source groups who have an interest to come forward and contribute to SVG.

[nikosandronikos]

It's worth reading https://www.w3.org/wiki/SVG/Animation if you haven't already.

[tabatkins]

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.

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.)

You cannot use CSS to animate SVG from inside the SVG file.

Yes you can. What makes you think you can't?

It is also impossible to use CSS on mobile apps, while SVG animated Icons with SMIL are used by many iOS and Android applications.

This is a weakness of some of the tools rendering SVG, not an intrinsic weakness of the platform.

But until then, SMIL is the best format for animations and should be the default for SVG.

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.

[tabatkins]

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.)

[Emasoft]

Here are some examples of SMIL features missing from CSS:

• Unmatching repeatCount per display element: one powerful feature of SVG/SMIL is the ability to not only independently animate the properties of a single element, but also control the repetition of each of those properties. CSS does not have this kind of control.
• Repetitions with an initial delay.
• Interrupting non-discrete animations.
• Animation event attributes: onbegin,onend,onload,onrepeat.
• Additive and cumulative behaviors.
• Specific time values: accessKey, event, repeat and wallclock-sync time values.
• Syncbase values: synchronizing multiple instances is an issue in CSS as the delays won't always start at the same time.
• calcMode="paced"

[Emasoft]

@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.

[nikosandronikos]

@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?
https://w3c.github.io/web-animations/#paced-keyframe-spacing-mode

[Emasoft]

@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:

Web Animations doesn't have the same features as SMIL, so we may encounter cases that never get supported properly.
calcMode="paced" won't be supported when we use native Chrome Web Animations, as paced Web Animations animations haven't been implemented natively.
Implementing animateMotion using CSS Motion Path might not be perfect, I don't yet know what the limitations will be. For example, if an author used animateMotion and transform/animateTransform on the same element, I don't know if the polyfill will match native SMIL.

The differences are still huge and you cannot say that WebAnimations is backward compatible with SMIL.

[birtles]

Hi, implementer of SMIL in Firefox and Web Animations / Animation Elements spec editor here. Regarding features:

• Unmatching repeatCount per display element: one powerful feature of SVG/SMIL is the ability to not only independently animate the properties of a single element, but also control the repetition of each of those properties. CSS does not have this kind of control.
  

This is achieved by having multiple animations the same as it is in SMIL (unless I'm missing something here?)

• Repetitions with an initial delay.
  

As in a per-repeat delay? How do you do this in SMIL? With values? Or with syncbase timing?
The values option is already possible in CSS. For syncbase timing, we're looking at adding timing groups in the future which would give you this. We tried adding per-repeat delay but it was difficult to work out what fill mode to use during the repeat delay (amongst other issues).

• Interrupting non-discrete animations.
  

What do you mean by this?

• Animation event attributes: onbegin,onend,onload,onrepeat.
  

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.

• Additive and cumulative behaviors.
  

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.

• Specific time values: accessKey, event, repeat and wallclock-sync time values.
  

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.

• Syncbase values: synchronizing multiple instances is an issue in CSS as the delays won't always start at the same time.
  

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.

• calcMode="paced"
  

As @nikosandronikos pointed out the web animations model does have an equivalent for calcMode="paced"in spacing modes. Once we implement that and the spec there stabilizes, we can investigate how to expose it in CSS.

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).

[progers]

@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.

[Emasoft]

@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.

[birtles]

@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.

[Emasoft]

@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 most common: if you say that all those things are possible please tell how to Steve Vachon [email protected] . We were using his smil2css library in our old web exporter.

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.

[nikosandronikos]

@Emasoft Perhaps you could point Steve Vachon here instead.

[Emasoft]

Done.

[Emasoft]

Why is this thread been closed? This issue is not yet resolved. Please reopen this thread.

[stevenvachon]

@birtles believing that the items in the "most common" limitations list are possible with CSS (and without JS) and proving so are two entirely different things. This isn't religion. I'm interested in your solutions if you have them. I see them now. Perhaps I need a coffee first.

[Emasoft]

@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?
@AmeliaBR can you answer this? You says that SMIL will be "one of the three equally valid approach". This means that SMIL is still part of the SVG specifications, and that it will be perfectly supported in the future? Just rewired internally in web animations, but the SMIL markup inside SVG will not require to be modified? This is a fundamental point. As I said, SMIL is the lingua franca of vector animations in all animations studios in the world. Software used by professional animators like Adobe Animate CC, Anime Studio Pro, CACANi... all those have plugins that export animations in SMIL as a single SVG file. Those file are exchanged all over the world, and allow people, designer, artists, in-betweeners, to work remotely and collaborate. SMIL is amazingly powerful, a real gem. No other animation file format can be compared to it, not even proprietary formats. It is so good that, with the exclusion of the web world, all those who embraced it in the last decade are still using it today. The web was an anomaly. SMIL was not accepted because of Microsoft economical interest in killing it, because it was in competition with their own vector animation format (the now dead XAML).
But nobody ever criticized SMIL. It was the most plauded and appreciated format ever. Now that Microsoft changed its strategy and embraced the web standards at last, SMIL can finally become the king of the animation formats on the web. And now the SvgWG decides to drop it? Why?
You said that companies like the one I work for should start partecipating in the activities of the svgWG. But why we should work to fix something that it is not broken? The SMIL standard works perfectly, and we are developing tools to help animators using it. The WG out of the blue decides to drop a successful animation format that is still unsurpassed for both features and flexibility, and to create another format, much less flexible because too linked to the browser and the web to be truly portable, in its place. And the WG expects that the companies that are going to be damaged by this choice economically will invest more time and resources in solving the problem that the WG created?
This doesn't make sense. Why are you betraying the trust of all companies and artist that put their faith in your vector animation format? What kind of credibility the next animation format is gonna have? Who is going to invest in it? Surely not my company. It is much better to invest in a proprietary format if this happens. And this means that nobody is gonna create tools for artists in your new format, with the effect of making the web ugly and still dependent on script kiddies that writes CSS instead of professional artists that can create their art visually with our tools. Dropping SMIL is like dropping JPEG or PNG. With the only difference that while for bitmaps images there are already many good standards on the web, for animations outside of SMIL we have nothing. Do you know a single animation software that saves animations in SVG+CSS or SVG+WebAnimations? I don't. Try to save a 20 minute SVG cartoon ANIMATION in unsyncronized CSS or Web Animations. Try to import them in Adobe After Effect or in the apps I mentioned before. You can't. Do you really expect that the animation industry is going to use CSS and javascript to make the next anime blockbuster? Why don't you call the CACANi company in Singapore, and ask them if they would ever use such format. The answer would be most likely a laugh.
Try to ask Viber, that with its popular audio communication app is replacing standard voice calls all over the world, if they would stop using their cool animated emoticons made in SVG+SMIL and start using WebAnimations or CSS instead. If SMIL die, nobody is going to use SVG anymore because animating it would be impossible without animation tools. No professional graphic artist is going to learn how to code animations or the intricacies of CSS, because art is a visual skill. This is why Flash was so popular while it lasted: because artists were using an editor to create animations, not code or markup. So if you are going to kill SMIL you are going to lose the trust of all tools developers and of all artists. Everyone that works in this field would be hurt. Is all this really necessary? You said that the WG group discussed this for years. So, tell me: what possible reasons the group found so compelling that killing SMIL was the only option? Why the new animation standard cannot be just a superset of SMIL, perfectly backward compatible with the existing format?

[birtles]

@stevenvachon Could you explain what you mean by:

Multiple CSS animations per element are not possible. However, the reuse of elements (via <use>), each with a CSS animation and initial delay could work, though not consistently due to the following point.

You can have a list of animations, e.g. animation: spin 1s, glow 2s, fade 2s 4s. What's more you can add and remove from that list without disturbing existing animations. The one thing you can't do, however, is have multiple animations targeting same property. The animation-composition property mentioned earlier in this thread should let you do that in CSS Animations 2. Splitting transform into separate proprerties like translate, scale etc. in CSS Transforms 2 lets you avoid clashes for some types of animations in the meantime (currently implemented in Chrome, I believe, and work is underway in Firefox too, I think).

[Emasoft]

@birtles You just wrote:

...the property xxx should let you do that in CSS Animations 2...
...splitting transform into xxx in CSS Transforms 2 let you avoid this..

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?
But this is not what we were discussing. You said that you can do a perfect translation of SMIL to CSS now, not in the future. The issue was: why the current SMIL standard that is already capable of all those features is now being dropped for a lesser standard like CSS, that does not support all SMIL features yet? Answering that the working group will add this in the future is not a valid answer, because if you have to fix CSS to make it as powerful as SMIL, then you can spend in a much better way your resources improving SMIL. This is like a carpenter that needs some tool to do a job, saying that because one of his two tools is broken and the other is fine, then it is better to throw out the good one and to fix with a prosthesis the broken one instead, and using it to do the the job.

[tabatkins]

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.

[Emasoft]

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.

[stevenvachon]

@Emasoft I can't give an official answer, but it really appears as though SVG Animations will be backwards compatible with SMIL, at least in the long run and in the browsers that choose to support it. MS Edge currently has no plans.

[tabatkins]

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.

We need to know if you are really going to break compatibility with something that works so well.

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.

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?

There is no such distinction.

[Emasoft]

@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.
Yes, as I said in the other thread, the google position about killing SVG and everything XML because of low usage on the web, is the crux of the matter here. The original sin. The trouble with that approach is that is MIOPIC. What google does not understand is that you cannot fence the web like an independent world. The web development is not using XML, yes, but it depends on a world outside of artists, designers, graphic applications, that does use XML and many other standards to work. The web is not an island. If you want it to grow and to improve, you need to ensure the presence of a supply road from the world of artists and graphicians. And such supply road is made of COMMON standards like SVG. Microsoft did't understand this. And this is the reason because Microsoft failed with XAML, the reason because no artists ever used it, and the reason because the web waited 20 years to wake up and discover vector graphics, while in the mean time SVG was becoming popular with videogame creators, animators and studios and was being used to make the graphics of blockbusters anime and videogames made in singapore and tokyo. If you don't wake up and start to see that IT IS ALL CONNECTED, you are going to create a web where the graphics is made by non artists but only by css programmers with no artistic competences. And that, I assure you, is NOT gonna make the web a pretty place, and it is going to choke Google projects for the web like it choked those of Microsoft.

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 ).
I hope of being able to do it in the future.

[tabatkins]

Why are you killing something that works?

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.

Please at least discuss it before deciding about it. It is in all best interests.

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.

P.S. I also inform you that I'm going to write an article about the official SvgWG answer

I'm an SVGWG member, and am representing the WG opinion here to the best of my knowledge.

[nikosandronikos]

I think @tabatkins has fairly accurately covered the situation.
Though it's also all laid in that wiki page I linked to above, so that should be considered the definitive view of the working group.

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.
So while SMIL is currently broken on the public web, if applications are only to run on known engines that support SMIL (e.g. perhaps Viber uses iOS web view), then SMIL can continue to be used. And in those contexts SMIL support may remain for a long time - driven by that heavy usage, and a replacement backwards compatible declarative syntax for SVG Animation based on Web Animations becomes very important. There is certainly support for this from some in the SVG working group.

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.

[Emasoft]

Thank you all for your concern and your indulgence. It is a rare thing.
@nikosandronikos I will surely write about it very soon. I'll let you know.

[stevenvachon]

@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 😉