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.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
CSS animations will have path support soon. :)
On May 16, 2015, at 3:19 AM, 'Elliott Sprehn' via blink-dev <blin...@chromium.org> wrote:CSS animations will have path support soon. :)
On May 16, 2015 7:31 AM, <chris...@google.com> wrote:YouTube is planning on using SMIL for various animations in the new player. Join it here: http://www.youtube.com/testtubeThere are various effects we cannot do without SMIL such as the Play/Pause button animating path. It would be a shame to lose this as theres no way to replicate that feature with CSS alone.
On May 16, 2015, at 12:02 AM, Joe Doll <Joe....@IFR-Everywhere.com> wrote:Besides javascript and SMIL, SVG can be programmed. When SMIL is removed, will SVG programming also be removed? SVG programming primarily uses SVG events such as begin and end, and that usually triggers other animations. I'm only asking because we have 10 to 15 pages that use SVG events. They can be changed to CSS events, I think.
Hello Blink community,
The API owners met and discussed the comments and use cases for SMIL raised in this thread. We concluded that SMIL has low usage, is not on track to ever get support across all browsers, and that the primary use cases are either already solved or will almost all soon become so.
Based on these factors, we feel that the right thing to do is deprecate SMIL now, and remove it at a later date once usage is below an acceptable threshold and enough use cases are supported via alternate mechanisms.
Note that when removal of SMIL is proposed in the future, a new Intent will be required.
There are two major different classes of use for SMIL: animation of in-page SVG content, and animation of SVG images. In the former, script is allowed, but in the latter, it is not, which is an important distinction because no script means no Web Animations.
The Web Animations API is on a path to providing complete coverage of SMIL features, and projects like Eric Willigers’ SMIL emulation can continue to provide SMIL affordances for authors who want them into the future.
As brought up in this thread, however, SVG images (i.e. SVG contained within an <img> tag) is an important use case, because of its declarative representation and simplicity for embedding in pages.
Earlier in this thread, Brian Birtles gave four examples of the key use cases that are important for SVG and are currently not feasible for SVG images without SMIL. Below we list them together with expected improvements to those use cases in the future.
Animating path data
Exposing SVG attributes as CSS properties is a goal of the SVG WG, and will provide this ability as a side-effect.
Animating viewBoxes
There are multiple approaches that provide the same effect, including animation of transform values on a top-level element that clips.
Synchronizing and sequencing animations
It is currently possible to manually synchronize and sequence animations via the use of animation-delay values and a forced-atomic style update.
Adding independent animations together This is a missing primitive with no simple workarounds. [Note however that Web Animations is spec’ed to have this feature in the future.]
On 20/05/15 20:36, Chris Harrelson wrote:
> [...]
> SVG images
>
> As brought up in this thread, however, SVG images (i.e. SVG contained
> within an <img> tag) is an important use case
[...]
> *
> Adding independent animations together
>
> This is a missing primitive with no simple workarounds. [Note
> however that Web Animations is spec’ed to have this feature in
> the future.]
The latter wouldn't be available because SVGs referenced by an img tag can't use JS.
Tobi
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Web Dev:
https://twitter.com/tobireif
http://tobireif.com
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
On 2015/05/21 3:36, Chris Harrelson wrote:
> The API owners met and discussed the comments and use cases for SMIL
> raised in this thread. We concluded that SMIL has low usage, is not on
> track to ever get support across all browsers, and that the primary use
> cases are either already solved or will almost all soon become so.
I'm less sure of this. Microsoft have commented that they are open to
the idea of a native JS implementation of SMIL built on Web Animations
so I don't think the assertion that SMIL "is not on track to ever get
support across all browsers" is accurate unless you are specifically
concerned about IE as opposed to Edge.
Adrian wrote:
> We are open to the idea of a JS implementation if it becomes
> absolutely necessary.
"JS implementation" refers to implementing SMIL animation inside the
browser (using JS), correct? (as opposed to someone implementing it as a
JS lib/polyfill for web devs)
Thanks for the reply. It will be a considerable amount of work to switch to one of the alternatives which may not even work with Google Maps custom overlays. I would also be concerned about the performance of the alternatives compared to the native SMIL interface. My application uses thousands of AnimateColor polyfills to achieve the thematic overlay animation effect. A lot of performance work has been done in the non-IE browsers over the last 3 years to get to the point where SMIL is currently performing very nicely. If anyone can point me to any relevant performance data on the alternatives I would be interested.
Also you seem to now be talking about removal where previously I thought we were only talking about deprecation?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
By "deprecating" do you mean that Chrome will still run SMIL animation but will not get any technical update per SMIL specification? I just begin learning making SMIL animation in standalone SVG but I fear that Google's decision is not sound. SMIL allows graphists to make animation without knowledge of scripting or where scripting is forbidden due to concern of security. Particularly I want to know if there's any straightforward replacement of SVG path morphing with CSS animation, but I expect there is none.
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.
You seem to have taken the "Internet Explorer does not intend to implement SMIL" as a larger argument than it is.
- SMIL is very little used.
- SMIL adds major complexity to the engine.- Most of SMIL can be implemented using other technologies.Those are the prominent arguments.
And for your information, Internet Explorer (and Edge) breaks backwards compatibility just as well as Chrome,
if not more (VBScript, VML, XML Data Islands and data bindings, attachEvent and the list goes on). The only difference is that Internet Explorer implements a multiple engine strategy (which is deprecated now and was never advised to be used long term) that lets you load an older engine, deprived of speed, advances, fixes, standards compatibility and new features. Edge does not have the older engines anymore, so it also breaks backwards compatibility.
And if you have not been bitten by a broken Firefox release, you are either lucky, or you just did not notice. It happens to all of the browsers. The nature of human
error.
On Sunday, 16 August 2015 08:25:29 UTC+2, PhistucK wrote:You seem to have taken the "Internet Explorer does not intend to implement SMIL" as a larger argument than it is.
- SMIL is very little used.Define very little. A percentage says nothing, but the total number of developer hours to replace it globally.
0.000403*(5*10**8)/(240*8) ≈105 man years to replace SMIL.
That is an irrelevant calculation. The percentage is of the number of page views, not the number of sites. There may be 100 sites that use it in all of their pages and the number goes up in an instant.For example, YouTube, used SMIL to their new video player, released a few weeks ago. I reckon this will increase the percentage (or already increased it), but it is a single player that will fix countless pages (any embedded video included).This is probably why the number has increased.
Why is it flawed? Page views matter more than the number of websites. If you have a website that uses SMIL on one of its pages but no one visits that page, it should not be counted towards the use counter of SVG, as is it unused by users.
The system is not trying to find websites that use SMIL, it is trying to detect the usage of the feature that users experience.Also, the count may be even more elaborate than that (but it does not count websites, I am pretty sure). I do not remember the exact method, sorry.
On Monday, 17 August 2015 18:43:06 UTC+2, PhistucK wrote:Why is it flawed? Page views matter more than the number of websites. If you have a website that uses SMIL on one of its pages but no one visits that page, it should not be counted towards the use counter of SVG, as is it unused by users.So what you are saying is that educational sites that use SMIL are less important than porn sites that use SMIL. Not to mention intra-net sites, which are completely unimportant by this fundamentally flawed metric. According to this "page view metric" the HasAttribute DOM function should be removed and many others along with it... Why stop at SMIL? Let every browser vendor destroy some random technology because it is only used on 10.000.000 websites and watch the web deteriorate.
The system is not trying to find websites that use SMIL, it is trying to detect the usage of the feature that users experience.Also, the count may be even more elaborate than that (but it does not count websites, I am pretty sure). I do not remember the exact method, sorry.No, if you increase the sample size you will mitigate these issues. Unless you are saying that smaller sites are less likely to use SMIL.
---Anyhow, to summarize:1. There are no good arguments for undermining declarative animation. Movement of objects are semantical, not presentational. If SMIL needs fixing, fix it, but don't destroy it.2. Scripts are woefully inadequate and dangerous as data (user uploads and verification).3. If you remove declarative markup from browsers, then editors are not going to support it. That basically means each editor will use a home-grown format.4. Editing animation scripts are more time consuming than tweaking svg-animation-elements, not only for designers, but also for programmers.5. It will take at least 3-5 years before we have an adequate and supported replacement technology because of the long tail.6. Opera had well working SVG animation over 12 years ago. It can't be that hard…7. If Opera and Mozilla could afford to do it, then Google can afford to do it.8. Instability is expensive for the rest of the world and Google's reputation when it comes to stability is not great. But Google do a good job with App Engine. It is nice, stable and don't change much. I guess the key difference is that on App Engine Google actually have developers as customers...
If users visit pages that use a feature, it matters. If a website that uses a feature is out there but users do not visit it, users are not hurt by the loss of the feature. This is the point of the counters, to make sure no one (or relatively "no one") is hurt by the loss of a feature.
Of course, the ratio changes according to the cost of maintaining a feature. A relatively costly feature like showModalDialog does not require an extremely low percentage (but still low), while a "free" feature like a simple constant (offscreenBuffering, for example) needs an extremely low percentage in order to be removed.If you have a better (sensitive to privacy and not intrusive) way of counting the usage, you may suggest it in a new thread.
In other words, SMIL can live and thrive, if a javascript engine is stuck into a file (or on the server) where SMIL is used inside of the SVG.
My SMIL interpreted by javascript is only 500 lines of javascript, but as I said, it is not a full implementation. It is a better implementation in that it works better.
This might be a way for everyone to go home happy.
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. 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 RiskMedium-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 developersThere 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?No, this is only an intent to deprecate and we plan to show a deprecation warning in the console.
I think they weren't really given a fair chance to be widely utilized on the web as can be seen by the big spike in usage after Chrome decided to deprecate them:I have a feeling their usage would continue to climb.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
And with SMIL you have the advantage of a self contained animation data file. Just an .svg file, that will reproduce everywhere (and forever, no code dependencies... a standard specification format) in the exact same way, independently from the application you are using.
Good animation apps export to SMIL. For example the Flash extension "Flash2Svg" outputs an SVG animation file defined with SMIL, no need for javascript:
https://github.com/TomByrne/Flash2Svg
Here is an example output file of a cartoon episode exported with Flash2Svg (warning: the embedded audio track makes the download sizing 1.4 megabyte):