Intent to deprecate: SMIL

[Philip Rogers]

Primary eng emails

ericwi...@chromium.org, p...@chromium.org

Summary

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 UseCounter

Usage 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 MDN

http://crbug.com/482689

Requesting approval to remove too?

No, this is only an intent to deprecate and we plan to show a deprecation warning in the console.

[1] https://status.modern.ie/csstransitionsanimationsforsvgelements

[2] https://twitter.com/ChromeDevTools/status/575327634319540224

[3] https://hacks.mozilla.org/2015/01/web-animation-tools-network-security-insights-font-inspector-improvements-and-more-firefox-developer-tools-episode-37/

[4] https://docs.google.com/document/d/1bg7CUyUszqdwmENY3JX6_PoQD6uHRCNcRPJMlC4qlkw/view

[5] https://github.com/ericwilligers/svg-animation

[6] https://www.chromestatus.com/metrics/feature/timeline/popularity/501

[Chris Harrelson]

LGTM to deprecate, with a specific milestone in the deprecation warning to also remove in the future. How about M45?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dimitri Glazkov]

LGTM2.

:DG<

[Philip Jägenstedt]

LGTM3. 0.0403% is a slightly higher usage than most deprecations and removals, is the idea to wait and see if outreach brings that number down, or to set a milestone for removal now?

[Joshua Bell]

On Wed, Apr 29, 2015 at 2:09 PM, Philip Rogers <p...@chromium.org> wrote:

Primary eng emails

ericwi...@chromium.org, p...@chromium.org

Summary

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.

What, no love for HTML+TIME?

I AM DISAPPOINT!

[Elliott Sprehn]

Without SMIL how does an author embed several animated .svg files without doing inline <svg> in the page. Do CSS animations work in svg documents today? What's the timeline on those working?

[Eric Willigers]

Yes, CSS animations work in SVG documents.

However JavaScript, and hence Web Animations, does not work in embedded .svg files.

[to...@tobireif.com]

It sure would be nice if you could keep on supporting SMIL/SVG animation.

For current projects, I'm not using it (and probably also not for future projects), there are so many better options (not the least of which is pure JS).

But it would be sad if existing content would break.

This SVG demo
https://twitter.com/TobiReif/status/555435531480629248
works in Firefox and Chrome. IE users are out of luck, but back then there was hope that one day all browsers would support SVG including SMIL animations.

I very much doubt I'll find the time to make the above SVG demo work in a potential SMIL-less Chrome.

It's troubling to think that when you create content and put it out there, a browser vendor might decide to break it. Also it represents a risk of losing a considerable amount of  time in the form of updating / re-implementing the content.

Tobi

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Web Dev:
https://twitter.com/tobireif
http://tobireif.com
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

[PhistucK]

Note that there is a polyfill (the intent post mentions that), so you might not need to do anything except adding the polyfill.

When you choose a technology that is not yet supported by all of the major browsers, you are taking a risk. A lof of developers do not understand the risk (or ignore it, hoping "everything will be fine") and use proprietary, prefixed, experimental or poorly supported features. I would not say that the browsers are at fault in these cases (they experiment, they want to converge, obviously and sometimes it does not work, or some browser backs out and decides not to implement something it was interested in implementing in the past, because there is a better way, or because the priorities have changed).

A developer has to be responsible just like a browser has to be...

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[v.van....@hva.nl]

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.

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/

 

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

As long as the browsers are still improving these new technologies I would argue that it's too early to deprecate. 

 

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.

I would agree very much with the "it's hard" argument if other technologies would replace all features of SMIL. But unfortunately, they don't.

[Tobi Reif]

Yes I saw the link to the poyfill, and given how varied the quality of
implementation support for SMIL/SVG animation itself is, I doubt it
would be nothing more than dropping in the polyfill. There was a bug in
Firefox that has been fixed ~recently [1], and I still have to report
one for Safari (both for just this one demo).

Oh yes, we all knew we were taking quite a risk back in 2000 when we
created a lot of SVG content and read the 600 (or 800?) printed pages of
the spec, and spread the word about SVG. There was no browser support at
all - we mainly used the Adobe SVG Viewer plugin. And we all did what we
can to promote SVG over proprietary technologies such as Flash. And we
tracked the first beginnings of native browser support and saw it grow
and grow.
Seeing it go backwards is quite strange I can tell you.

> use proprietary, prefixed, experimental or poorly supported features.

Well, it's been a finished W3C spec since quite a while.

For a tech demo (as opposed to a live/production web app) it isn't too
bad that it runs well in two major browsers (also considering all the
Chrome-only demos :) ).

Back to the one demo I linked:
If the polyfill works well then it's an option, but that remains to be
tested (correct support of all the features used, in all popular
browsers (or at least in Chrome and Firefox), on all popular OSs/devices).
I have no idea when I can find that time, after I recently made it work
in FF and Chrome.

Tobi

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1079836

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

Web Dev:
https://twitter.com/tobireif
http://tobireif.com
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

On 30/04/15 10:54, PhistucK wrote:
> Note that there is a polyfill (the intent post mentions that), so you
> might not need to do anything except adding the polyfill.
>
> When you choose a technology that is not yet supported by all of the
> major browsers, you are taking a risk. A lof of developers do not
> understand the risk (or ignore it, hoping "everything will be fine") and
> use proprietary, prefixed, experimental or poorly supported features. I
> would not say that the browsers are at fault in these cases (they
> experiment, they want to converge, obviously and sometimes it does not
> work, or some browser backs out and decides not to implement something
> it was interested in implementing in the past, because there is a better
> way, or because the priorities have changed).
> A developer has to be responsible just like a browser has to be...
>
>

> ☆*PhistucK*

[strelt...@gmail.com]

I believe that the existing support for SMIL should not be dropped before major browsers support CSS animation of SVG paths and things like http://dev.w3.org/fxtf/motion-1/

четверг, 30 апреля 2015 г., 0:09:31 UTC+3 пользователь Philip Rogers написал:

[PhistucK]

Unfortunately, a W3C Recommendation does not necessarily translate to excellent (or even any) browser support.

Microsoft has the "Not currently planned" status for it - https://status.modern.ie/svgsmilanimation?term=smil which generally means they will not pursue it. While this does not say they never will, the fact that this technology is so little used should indicate a risk of some sort.

☆PhistucK

[Paul Kinlan]

@pdr - can you make sure the Intent to Deprecate is added to chromestatus.com (for example https://www.chromestatus.com/features#deprecated).  We have been dinged a lot recently for not making the intent public enough.  Once it is up I can message it on our channels.

[Tobi Reif]

> Unfortunately, a W3C Recommendation does not necessarily translate to
> excellent (or even any) browser support.

And I didn't say it would.

SVG wasn't "proprietary" or "prefixed", and SVG itself wasn't
"experimental", it was a finished W3C spec. It wasn't implemented yet in
browsers, at all, and as I said yes I took that risk - I and many others
created early SVG content and promoted SVG in order to help popularize
SVG; this might have helped to increase the reasons for browser vendors
to implement it. "No one uses it" would've been an argument against
implementing it.

> Microsoft has the "Not currently planned" status for it -
> https://status.modern.ie/svgsmilanimation?term=smil which generally
> means they will not pursue it.

For this specific piece of existing content (a tech demo) I don't care
too much about Microsoft's browsers. If they implement SMIL+SVG that
would be nice, but I doubt it as well.

The trouble is that the great support that Chrome team has implemented
might get removed. I understand their motivation, but it does pose a
threat to existing content, even if there's not much of it, and even
though you say that breaking this content is the fault of web developers
not browser implementers.

I doubt that it will be a matter of dropping in the mentioned polyfill
and be done after a minute or two. Anyone who wants to prove me wrong is
very welcome :)

Tobi

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

Web Dev:
https://twitter.com/tobireif
http://tobireif.com
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

On 30/04/15 13:16, PhistucK wrote:
> Unfortunately, a W3C Recommendation does not necessarily translate to
> excellent (or even any) browser support.
> Microsoft has the "Not currently planned" status for it -
> https://status.modern.ie/svgsmilanimation?term=smil which generally
> means they will not pursue it. While this does not say they never will,
> the fact that this technology is so little used should indicate a risk
> of some sort.
>
>

> ☆*PhistucK*

> <mailto:blink-dev%2Bunsu...@chromium.org>.
>
>

[Eric Willigers]

On Thu, Apr 30, 2015 at 7:30 PM, <v.van....@hva.nl> wrote:

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.

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/

The Web Animations API supplies a unified API for animating CSS and SVG. To animate a blob's SVG attributes using JavaScript, run a recent build of Chromium with experimental features enabled.

Here is a port of your example using Web Animations: 

http://jsfiddle.net/ericwilligers/32veujy6/ 

If you wanted to move the blob along a path, that can be achieved (again with experimental features enabled) using the motion path CSS properties from http://dev.w3.org/fxtf/motion-1/

[mile...@gmail.com]

What about changing a path? Basic event triggers for animation? Without JavaScript so that it can be used in an img tag or CSS background where scripting is disabled?

The nice thing about SMIL is that you can lock down general scripting while still maintaining a great deal of utility on the same level as one has with HTML sans scripting. Polyfills won't help in that case. Uploaded user-supplied SVG is a real threat unless scripting is disabled while uploading images is clearly a common use case. We can upload animated GIFs safely but not animated SVGs 1/10 their size?

[Philip Rogers]

Mileselam,

The image issues you brought up are important to me too, but only 0.008% of pages are doing this with SMIL today. Maybe it's lack of tooling or lack of browser support but SMIL hasn't caught on with users like CSS animations have. Both developers and users will be best served if we add path animation functionality to CSS where it can work in all browsers.

[mile...@gmail.com]

And SMIL's event handling? That's not so easy with CSS except for hover.

I understand the code complexity issues. Honestly it's not about SMIL specifically; it's the lack of non-scripting alternative. It's promised in SVG2, and I hope the Blink team will publicly commit to supporting the declarative animation syntax with the rest of SVG2.

Supporting two declarative syntaxes would be slightly annoying. Not having any at all would be far worse.

And to be honest, SVG hasn't been heavily used until relatively recently, mostly due to lack of IE support. Mobile IE is a non-issue. Frankly I consider Opera Mini to be a non-issue for the use cases for SMIL. Now is the time with Android 2.x waning where SMIL can begin to be used more widely. Mobile support is finally there now and ready. Only now the Blink team has instilled a chilling effect on adoption by public warnings to deprecate.

OF COURSE it isn't used much. If you told people that the :target selector we're going to be deprecated, people would avoid that too. :-/

[karen....@gmail.com]

I'm a bit bummed out too, tbh. With all major browsers supporting SMIL and the FakeSmile polyfill, I know plenty of us were looking forward to animating paths and doing things that CSS keyframe animations aren't capable of, currently. The documentation for SMIL has not been great on the web and the spec for SMIL is pretty hard to decipher for us mere mortals. Perhaps this also slowed down usage? 

I think this article, https://css-tricks.com/guide-svg-animations-smil/ by Sara Soueidan really helped clarify working on SMIL in real world projects and has been an inspiration both to me and other devs. I understand that the declarative syntax within markup is not the most elegant to look at, but it definitely seems like a step back to deprecate, for something that has been a W3C Recommendation since 2008 :(

[Tobi Reif]

Hi Karen

> something that has been a W3C Recommendation since 2008 :(

Just FYI :)
http://www.w3.org/TR/SVG10/
"(SVG) 1.0 Specification"
"W3C Recommendation 04 September 2001"
http://www.w3.org/TR/SVG10/animate.html

Tobi

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Web Dev:
https://twitter.com/tobireif
http://tobireif.com
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

On 02/05/15 06:33, karen....@gmail.com wrote:
> I'm a bit bummed out too, tbh. With all major browsers supporting SMIL
> and the FakeSmile polyfill, I know plenty of us were looking forward to
> animating paths and doing things that CSS keyframe animations are

> capable of, currently. The documentation for SMIL has not been great on

> the web and the spec for SMIL is pretty hard ti decipher for us mere

> mortals. Perhaps this also slowed down usage?
> I think this article, https://css-tricks.com/guide-svg-animations-smil/
> by Sara Soueidan really helped clarify working on SMIL in real world
> projects and has been an inspiration both to me and other devs. I
> understand that the declarative syntax within markup is not the most

> /elegant/ to look at, but it definitely seems like a step back, for

> something that has been a W3C Recommendation since 2008 :(
>
> On Thursday, 30 April 2015 02:39:31 UTC+5:30, Philip Rogers wrote:
>

> *Primary eng emails*
> ericwi...@chromium.org <javascript:>, p...@chromium.org <javascript:>
>
> *Summary*

> 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 UseCounter*

> Usage is low but stable at 0.0403% of pageviews[6]. The top SMIL

> user is currently ign.com <http://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 <http://chromestatus.com>, crbug.com
> <http://crbug.com>, or MDN*
> http://crbug.com/482689
>
> *Requesting approval to remove too?*

> No, this is only an intent to deprecate and we plan to show a
> deprecation warning in the console.
>
>
> [1] https://status.modern.ie/csstransitionsanimationsforsvgelements
> <https://status.modern.ie/csstransitionsanimationsforsvgelements>
> [2] https://twitter.com/ChromeDevTools/status/575327634319540224
> <https://twitter.com/ChromeDevTools/status/575327634319540224>
> [3]
> https://hacks.mozilla.org/2015/01/web-animation-tools-network-security-insights-font-inspector-improvements-and-more-firefox-developer-tools-episode-37/
> <https://hacks.mozilla.org/2015/01/web-animation-tools-network-security-insights-font-inspector-improvements-and-more-firefox-developer-tools-episode-37/>
> [4]
> https://docs.google.com/document/d/1bg7CUyUszqdwmENY3JX6_PoQD6uHRCNcRPJMlC4qlkw/view
> <https://docs.google.com/document/d/1bg7CUyUszqdwmENY3JX6_PoQD6uHRCNcRPJMlC4qlkw/view>
> [5] https://github.com/ericwilligers/svg-animation
> <https://github.com/ericwilligers/svg-animation>
> [6]
> https://www.chromestatus.com/metrics/feature/timeline/popularity/501

> <https://www.chromestatus.com/metrics/feature/timeline/popularity/501>
>

[Brian Birtles]

I don't want to add any noise to this conversation, but I wrote up some very rudimentary ideas[1] about the gaps that would be left if SMIL disappeared and someone from Google suggested I feed that back into this thread.

I believe that Philip and co. are well aware of these issues but, for reference some of the obvious gaps would include:

* Animating path data
* Animating viewBoxes
* Synchronizing and sequencing animations
* Adding independent animations together

See the blog[1] for a more thorough description and some ideas of how we could fill these gaps.

I have a slight concern that the data used here might not be completely reliable since in a recent SVG WG meeting, together with the engineer who implemented the relevant use counters, we noticed that http://parapara.mozlabs.jp/, which use SMIL heavily, did not appear to trigger the counter. Nevertheless, I don't doubt that SMIL usage is low.

Best regards,

Brian

[1] https://birtles.wordpress.com/2015/05/01/what-do-we-do-with-smil/

[Philip Rogers]

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.

I was able to reproduce the UseCounter anomaly you saw on parapara.mozlabs.jp and I've uploaded a fix in http://crbug.com/484004. For performance reasons we cache the DOM for SVG images and this was causing cached image loads (e.g., refreshing the same page) to not trigger the SMIL UseCounter on subsequent loads. Lets push this deprecation back until we can at least get beta/dev numbers with an updated UseCounter. This will also give us a little more time to discuss this on www-svg.

[Tobi Reif]

Hi

If I were to test whether the recommended polyfill completely and
correctly supports the features that my existing content uses, how would
I disable SMIL/SVG animation in Chrome? Is there a command line flag?

Tobi

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Web Dev:
https://twitter.com/tobireif
http://tobireif.com
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

On 04/05/15 05:06, Philip Rogers wrote:
> 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.
>
> I was able to reproduce the UseCounter anomaly you saw on

> parapara.mozlabs.jp <http://parapara.mozlabs.jp/> and I've uploaded a

> *Primary eng emails*
> ericwi...@chromium.org, p...@chromium.org
>
> *Summary*

> 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 UseCounter*

> Usage is low but stable at 0.0403% of pageviews[6]. The top SMIL

> user is currently ign.com <http://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 <http://chromestatus.com>, crbug.com
> <http://crbug.com>, or MDN*
> http://crbug.com/482689
>
> *Requesting approval to remove too?*

[Eric Willigers]

Hi Tobi,

There isn't currently a flag, but that might be a good idea.

One approach might be to rename the SMIL tags in your content and in the polyfill. In smil-in-javascript.js, you would need to rename the tag names where they appear unquoted in observedTags, and quoted elsewhere in the file.

I haven't used the polyfill in Internet Explorer (which doesn't support SMIL), but that might be another possibility.

Eric.

[Tobi Reif]

Hi Eric

I hope there will be a flag.

I thought of renaming the elements, but I'd rather test the SVG as is
with the polyfill as is, in a Chrome with temporarily disabled SMIL support.
That would best simlate the actual worst case of Chrome actually
dropping SMIL.

> I haven't used the polyfill in Internet Explorer

I hope the polyfill will be tested in all major browsers which don't
support SMIL+SVG.

Dear Chrome devs, please consider adding such a flag, so that I/we can
test the polyfill(s) properly and conveniently.

Tobi

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Web Dev:
https://twitter.com/tobireif
http://tobireif.com
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

[strazzull...@gmail.com]

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

On Wednesday, April 29, 2015 at 11:09:31 PM UTC+2, Philip Rogers wrote:

Primary eng emails

ericwi...@chromium.org, p...@chromium.org

Summary

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 UseCounter

Usage 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 MDN

http://crbug.com/482689

Requesting approval to remove too?

[vector...@gmail.com]

We use SVG SMIL in places where CSS and javascript can't be implemented. For example, many PHP frameworks will not work correctly when CSS or javascript are implmented in the file, but SVG animation and SMIL will work.

Will SVG programming without SMIL be eliminated? We use that in about 10 places.

In my opinion, no technology should be deprecated without another technology that is already superior. SVG has no equal in CSS. Many things can be done in SVG that CSS won't allow. Of if CSS can do it, no one would understand the code.

Javascript competes well with SMIL, but at times javascript is not an option.

Javascript, itself, is great in many ways and awful in other ways. For example, the javascript arrays are awesome, but did you know that "do while" and "if else" won't work in many cases? We are going into an age of integration of software across many devices such as cell phones, web browsers, and server applications. It is a fundamental need to have tools that will allow us to integrate these usages, yet we don't have that in the browser. We have CSS, SVG, and javascript. None of those are C, python, perl, PHP, or even java. By eliminating SVG SMIL, you are subtracting from our limited options! We need more and stronger tools, and we are faced with a decreasing number of ways to do something.

If you consider web frameworks (such as Joomla), or complicated web applications (such as Google docs), you will find that you have places where SVG SMIL lets you squeak by. And now that flexibility will be deprecated. How sad!

[Dean Jackson]

On Monday, May 4, 2015 at 1:07:12 PM UTC+10, Philip Rogers wrote:

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.

I'm not so sure about that. As Brian said, we'd need to add features to CSS Animations in order to get the same level of functionality. I've made proposals for some of them (synchronisation/chaining, additive) and there is a proposal for motion paths in CSS. Some things still are not possible (viewBox). We'll slowly get there.

But in many cases SMIL is a cleaner way to author animations. You don't need to add ids to elements in order to target them. You don't need to declare keyframes separately from the animation attachment point.

Either way I think it's really important that a purely declarative animation feature is available to <img src="banana.svg">.

I think you alluded to the biggest issue with a SMIL implementation: the baseVal/animVal nightmare in the DOM. It would be great if we could nuke that and rely on the HTML/CSS DOM and computedStyle. Given that CSS is headed towards the same level of functionality as SMIL, how much easier would the implementation be. Is SMIL syntax the issue? 

Dean 

[Erik Dahlström]

Hi,

having looked at CSS Animations, the Web Animations scripting API and SMIL
it's clear that each of them has their strengths.

Further comments inline.

On Thu, 07 May 2015 23:33:31 +0200, Dean Jackson <di...@apple.com> wrote:

>
>
> On Monday, May 4, 2015 at 1:07:12 PM UTC+10, Philip Rogers wrote:
>>
>> 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.
>>
>
> I'm not so sure about that. As Brian said, we'd need to add features to
> CSS
> Animations in order to get the same level of functionality. I've made
> proposals for some of them (synchronisation/chaining, additive) and there
> is a proposal for motion paths in CSS. Some things still are not possible
> (viewBox). We'll slowly get there.

Yes, CSS Animations currently lacks some functionality that exists in
SMIL, and synchronization is probably not without costs. I'm hoping that
the gap(s) will be addressed sooner rather than later.

> But in many cases SMIL is a cleaner way to author animations. You don't
> need to add ids to elements in order to target them. You don't need to
> declare keyframes separately from the animation attachment point.

True, and this leads to SMIL having more compact representation in some
cases.

> Either way I think it's really important that a purely declarative
> animation feature is available to <img src="banana.svg">.

100% agree.

> I think you alluded to the biggest issue with a SMIL implementation: the
> baseVal/animVal nightmare in the DOM. It would be great if we could nuke
> that and rely on the HTML/CSS DOM and computedStyle. Given that CSS is
> headed towards the same level of functionality as SMIL, how much easier
> would the implementation be. Is SMIL syntax the issue?

If we look at the code itself in Blink, the core parts of the SMIL
animation engine hasn't really changed that much over time. What seems to
have changed more often/dramatically is how the animated values are stored
internally and how that has lead to various troubles with exposing that
information to the DOM and so on.

I am also of the opinion that the SVG baseVal/animVal DOM is, well, not
great :) I'm sure that most people that have used it would agree. OTOH
using get/setAttribute and string fiddling + parseFloat for all
lengths/numbers is not very appealing either. CSS OM isn't a full
replacement since it doesn't deal with svg attributes, though it can of
course help with the css properties. That's been possible to do for quite
some time, and I think that's all good, even if the CSS OM has its own set
of issues :)

Removing the baseVal/animVal DOM has compat risks associated with it.
Unfortunately I think those risks are somewhat higher than that of
removing SMIL, at least when it comes to baseVal. Feel free to try it out
yourself in a recent Chrome/Opera by passing in the commandline flag
"--disable-svg1dom". That flag will not disable SMIL, just disable a lot
of the SVG DOM interfaces exposed to scripts. It would most likely be
painful to drop the baseVal/animVal DOM, but it should also allow for
future code improvements and hopefully easier code maintenance, which in
the long run is a positive thing. If this is done, it would be good if all
browsers did this in the same timeframe to minimize the pain as much as
possible.

In general I'm unimpressed by the SMIL polyfills I've seen. Typically they
require that you adapt to a very limited subset of SMIL for things to work
at all == not that much simpler than rewriting the content, or simply not
caring about the browser(s) that doesn't support SMIL. And like others
have already said, scripted polyfills don't work unless scripting is
enabled (thinking of svg-in-img in particular).

I'm a bit concerned over the fact that web animations for svg hasn't
really been widely tested yet, there are bound to be bugs and gaps in
functionality here. Replacing SMIL (which has been shipping for quite some
time) with something that's essentially untested is a bit sketchy IMHO.
That situation should hopefully improve over time, and I think Web
Animations is a very nice improvement for scripted animations overall.
However, there is no clear replacement for the declarative syntax, and
both Web Animations and CSS Animations can get pretty verbose in
comparison to SMIL.

Cheers
--
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group

[pe...@animatron.com]

We at Animatron recently proved that SVG SMIL can be used for sophisticated animations similar to the ones produced in Flash. Amongst the main reasons for deprecation you mention fairly low usage of SVG SMIL by your users which we believe was caused by a lack of freely available powerful animation production tools capable of preparing professional grade SVG SMIL animations, which we now enabled (this was specificly indicated to us by our user feedback). Yes, there are many design and implementation issues plaguing SMIL and we are looking forward to have most of them (hopefully) resolved in Web Animations someday, however as we managed to support very advanced features in SVG SMIL that weren't considered during its design process such as time-reversal, multimodal easings etc., found workarounds for most of the outstanding issues via JavaScript (audio etc.) and the remaining issues we know of are fairly minor, we would like to ask you to reconsider your decision to deprecate SMIL in Chromium.

As with any developing standard, the state of Web Animations support/compatibility is not known in advance and it might take multiple years to get to the required level in leading browsers for wide-spread use. It would be an unfortunate effect to relegate more-less working SVG SMIL into a 2nd class citizen due to being deprecated by Blink.

We agree with Erik's assessment that baseVal/animVal design is not great, however it enables us proper automated regression testing in the browser once a few helper functions hiding implementation details are prepared.

Please have a look yourself at some examples of what is now possible with SVG SMIL (especially in Chromium!):

http://www.squared9.com/svg-smil

(not a fast server so you might want to download files first)

We hope these examples will be encouraging and confirming to you that your hard work was not done in vain but rather enabled such animations to play in most contemporary browsers and empower content creators that wish to use an already available and finalized W3C standard!

We will be happy to assist you with our experience preparing an advanced SVG SMIL publishing tool for reconsidering your stance on deprecating SVG SMIL.

Kind regards,

Peter Skvarenina

Geometry algorithms & SVG SMIL publishing

Animatron LLC Cambridge, MA

[chris...@google.com]

YouTube is planning on using SMIL for various animations in the new player. Join it here: http://www.youtube.com/testtube

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