To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Primary eng emailsSummaryWe intend to deprecate SMIL animations in favor of CSS animations and Web animations.MotivationSMIL (pronounced “smile”) is a declarative animation system that pioneered animations on the web and inspired both CSS animations and Web animations.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
MotivationSMIL (pronounced “smile”) is a declarative animation system that pioneered animations on the web and inspired both CSS animations and Web animations. SMIL was never implemented in all major browsers which limited its use and spec development slowed after the last spec update in 2008. We would like to deprecate our SVG-specific SMIL implementation and double-down on support and tooling of integrated HTML & SVG animation models: CSS animations and Web animations.
For content authors, browsers are actively improving the SVG animation experience without SMIL. Microsoft just announced CSS animation support for SVG[1] which means authors can, for the first time, create an animated SVG image that works in all major browsers. Both Chromium[2] and Firefox[3] are actively developing CSS animation and Web animation tooling which will work for SVG content too. Eric Willigers has also created a SMIL polyfill implemented entirely on the Web Animations API[5].
In terms of implementation, SMIL adds significant complexity to Blink. In the past year we had two large efforts to rewrite the tear-off implementation[4] (this supports ‘live’ animated values) as well as a difficult integration with Oilpan. Deprecating SMIL will help us focus on more general animation issues.
MotivationSMIL (pronounced “smile”) is a declarative animation system that pioneered animations on the web and inspired both CSS animations and Web animations. SMIL was never implemented in all major browsers which limited its use and spec development slowed after the last spec update in 2008. We would like to deprecate our SVG-specific SMIL implementation and double-down on support and tooling of integrated HTML & SVG animation models: CSS animations and Web animations.This would be a good idea if other web technologies are able to do everything SMIL can do. As far as I know, this is not the case though. For instance, can you animate a blob with CSS or JavaScript? — http://ghehehe.nl/random/shapes/bezier/animated/
Hold it!
The value of artwork can not, and must not be measured by a fantasy percentage scale. What guarantees that the 0,0403% figure is accurate? How was it obtained? I, or anyone, can probably point to works that are not included in that figure.
Value means any kind of value: affective or commercial; value for its creator and for others, whom the creator, or we, may not know; intrinsic artistic value; etc.
To base a deprecation proposal on that argument is weak. To base it on the argument of existing alternatives seems arbitrary, authoritarian, and optimistic.
You cannot any longer dissociate art and science. The implementation of SMIL in SVG has multiple facets, and that includes the artistic aspect, in particular the possibility for artists, illustrators, comics authors, etc. without coding knowledge to produce works, which accounts for one of the aspects that made SVG universal. All things that may not seem important to you or me, but may be very important to others. Give them a real chance (like ASV did).
You invoke other biases, but as you can read in some recent posts on this subject on the SVG developers list, there are quite a few concerns about what those other means are lacking. My opinion is a bit more radical: those tools are like Swiss knives, great for what they're designed for, but you can't possibly dream of building a space ship or a wooden cabinet with a Swiss knife, can you? Can you think of building a player for scrubbing an animation back and forth by dragging the timeline, with reverse playback, stop <, <<, >, >> and breakpoints? This was done in 2004 for monitoring processes in a SoC, thanks to SVG + SMIL + JavaScript (BTW, also consider what would happen to the commands for driving animations in SVG's JavaScript binding, a concern expressed in one post).
CSS animations and web animations or whatever, are the result of a destabilization campaign designed to obfuscate SVG in favor of CSS, a campaign promoted (for whichever reasons) by Chris Lilley, the hit-and-run man, with the help of his troll. The campaign was designed to make believe that this or that would be easier for those with CSS knowledge. The same “reason” behind the poisoned binding of CSS to SVG. The only result is the situation of confusion that we can witness now –predicted by some– and the risk of bastardization of SVG. The truth is that anything is easy if you know how to do it, and if you want to master a powerful tool like SVG, with all its features, you have to study it. If you need to do “serious” work that's the only way to go. But if you only need to do demos, or commercial banners, or some sort of fancy media reproduction, you can use web animations if that makes you happy. But leave the SVG spec alone, please.
You raise the argument of the limited use, but that shows precisely the reason why its use was limited: the implementation work was never done correctly in the browsers, with the exception of Opera (which at some point decided to adopt another SVG implementation).Instead, the implementation in the defunct Adobe's ASV was correct, viable, and almost complete (or was it complete?), and that explains why most SMIL works were produced in the first few years after 2000.
As a proof of fact, shall I show you the link to the movie “Schizophrenia”, whose preview was presented at The European Workshop 2006 in Zurich, made entirely with SMIL? It run perfectly in ASV, and then fairly good in Opera. It was never finished. Why? Because, when ASV went, attempts to complete the work on the other platforms (Opera, Firefox, Chrome, Safari) showed that it was simply unfeasible; too many differences, too many unsynchronized or broken interpolations, things not being rendered... Impossible to continue development. Some of the work is based on motion capture (from video).
There is a specification, but the browsers' developers haven't done, or aren't doing their implementation work correctly. This causes prejudice.
The proposal for deprecation sums up to admitting that you really can't do it. While instead ASV did it, good and fast.
Back to the value of works, to take my particular case as an example, the percentage of time I spent on gallop.svg (also motion capture and paths interpolation) is infinitesimally small compared to the time I consecrated to Pergola over the years. But you know what? It's value to me, and probably others, is way way greater than what the time percentage suggests. Sure, it “only” has an artistic and/or affective value. But would anyone suggest that the value of things be only measured by their commercial interest, or by some imaginary figure about their deployment? If one does, it's one who doesn't know, an ignorant.
Internet Explorer is a case of its own. They traditionally oppose resistance at the beginning to whatever comes from “outside”. At times that beginning can be kind of long. That's because they need time to understand. But eventually they come to it. In the case of SVG I must say they did a beautiful implementation, but they failed to understand the interest of <foreignObject>, SMIL, and SVG fonts. I'm very confident that ultimately they will implement those specs. The case of <foreignObject> is already settled in Project Spartan. For SMIL there's a petition on MSDN for its implementation; I can't find the link right now, but I'm sure you can, and you can sign it instead of suggesting deprecation.
Incidentally, the <foreignObject> implementation is inconsistent between Firefox, Opera, Chrome, Safari. It would be nice to have things fixed. It would also be nice to get the SVG 1.1 implementation completed in all browsers before worrying about other things, like what should or should not be deprecated. Can we first get it to work 100% once and for all, and then see? Can the browser vendors fulfill their engagement, or can they not? Are they actually capable of finishing the job, or not?
Let me report here some “arguments” by Microsoft for not implementing SMIL in SVG:
“… support for SMIL animation of SVG in the web development community is far from strong. The leader of the SVG standardization effort wrote that not supporting SMIL in its current state is probably best “since the SVG WG intends to coordinate with the CSS WG to make some changes to animation and to extend filters.” There’s already work started to reconcile CSS3 animations and SVG.“
”Although declarative animation is straightforward, it can also be limiting. In the words of David Eisenberg, author of SVG Essentials: "If you choose to use scripting to do animation, you will then have available all the interactivity features of scripting; you can make animation dependent on mouse position or complex conditions involving multiple variables."
That is, script-based animation opens the door to simple as well as complex animation possibilities. Because of this, and for other reasons (such as CSS animations), Internet Explorer does not support declarative animation. Undeniably, there can be more work associated with script-based animation, but once these scripting techniques have been mastered, you can implement animations impossible using purely declarative animation techniques. The following example, which is the JavaScript version (in HTML5) of Example 1, shows some of these techniques:“
It seems they're missing the whole point about which is the main intent for SMIL. It also shows how, instead of positively thinking of what you can do with a spec, they negatively see what you can't do. In other words it seems some people fail to grasp what a spec was designed for, and prefer to retain what it was not designed for!
To conclude, you provide two non valid arguments in support for deprecation. Here I have provided a few others, albeit not enumerated, and others have provided more arguments. Your arguments are no match. Please implement SMIL correctly and then you can stop worrying about it.
Thank you.
Domenico Strazzullo
We intend to deprecate SMIL animations in favor of CSS animations and Web animations.
Motivation
SMIL (pronounced “smile”) is a declarative animation system that pioneered animations on the web and inspired both CSS animations and Web animations. SMIL was never implemented in all major browsers which limited its use and spec development slowed after the last spec update in 2008. We would like to deprecate our SVG-specific SMIL implementation and double-down on support and tooling of integrated HTML & SVG animation models: CSS animations and Web animations.For content authors, browsers are actively improving the SVG animation experience without SMIL. Microsoft just announced CSS animation support for SVG[1] which means authors can, for the first time, create an animated SVG image that works in all major browsers. Both Chromium[2] and Firefox[3] are actively developing CSS animation and Web animation tooling which will work for SVG content too. Eric Willigers has also created a SMIL polyfill implemented entirely on the Web Animations API[5].In terms of implementation, SMIL adds significant complexity to Blink. In the past year we had two large efforts to rewrite the tear-off implementation[4] (this supports ‘live’ animated values) as well as a difficult integration with Oilpan. Deprecating SMIL will help us focus on more general animation issues.
Compatibility Risk
Medium-Low: Internet Explorer does not support SMIL which limited its use for critical functionality. A concern is existing SMIL communities and content authors: we will use developer outreach to minimize risks here.
Alternative implementation suggestion for web developers
There are three migration strategies:1) CSS animations.2) Web animations.3) Javascript polyfills such as Eric’s SMIL polyfill based on Web animations or fakesmile.
Usage information from UseCounterUsage is low but stable at 0.0403% of pageviews[6]. The top SMIL user is currently ign.com which only uses SMIL for a minor effect. Usage of SMIL inside images (i.e., <img src=”...svg”>) where javascript polyfills will not work is lower at 0.006% of pageviews.Entry on chromestatus.com, crbug.com, or MDNRequesting approval to remove too?
Brian,You're certainly not adding noise; those are great points.For folks less familiar with SVG, we currently have three modes for SVG content:1) Inline, for example: <html><svg width="100" height="100"><rect width="100" height="100" fill="green"/></svg></html>.2) Standalone documents, such as when you open an SVG file directly.3) SVG-in-image, for example: <img src="foo.svg">.Javascript is disabled in #3 (primarily for security) so we can only use CSS animations which do not support all of SMIL's features.From a web platform perspective, my hope is that this deprecation will increase overall web compatibility as content is refactored to work in IE/Edge too. I think this increased compatibility will outweigh the feature gaps in case #3.