Intent to deprecate: SMIL

16848 views
Skip to first unread message

Philip Rogers

unread,
Apr 29, 2015, 5:09:31 PM4/29/15
to blink-dev, Eric Willigers
Primary eng emails

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

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


Chris Harrelson

unread,
Apr 29, 2015, 5:12:54 PM4/29/15
to Philip Rogers, blink-dev, Eric Willigers
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

unread,
Apr 29, 2015, 5:14:08 PM4/29/15
to Chris Harrelson, Philip Rogers, blink-dev, Eric Willigers
LGTM2.

:DG<

Philip Jägenstedt

unread,
Apr 29, 2015, 6:07:53 PM4/29/15
to Dimitri Glazkov, Chris Harrelson, Philip Rogers, blink-dev, Eric Willigers
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

unread,
Apr 29, 2015, 6:26:21 PM4/29/15
to Philip Rogers, blink-dev, Eric Willigers
On Wed, Apr 29, 2015 at 2:09 PM, Philip Rogers <p...@chromium.org> wrote:
Primary eng emails

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

unread,
Apr 29, 2015, 9:32:47 PM4/29/15
to Joshua Bell, Philip Rogers, blink-dev, Eric Willigers
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

unread,
Apr 29, 2015, 9:56:11 PM4/29/15
to Elliott Sprehn, Joshua Bell, Philip Rogers, blink-dev
Yes, CSS animations work in SVG documents.

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

to...@tobireif.com

unread,
Apr 30, 2015, 4:38:07 AM4/30/15
to blin...@chromium.org, ericwi...@google.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

unread,
Apr 30, 2015, 4:54:48 AM4/30/15
to to...@tobireif.com, blink-dev, ericwi...@google.com
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

unread,
Apr 30, 2015, 5:30:52 AM4/30/15
to blin...@chromium.org, ericwi...@google.com
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

unread,
Apr 30, 2015, 5:32:53 AM4/30/15
to blin...@chromium.org
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

unread,
Apr 30, 2015, 5:38:15 AM4/30/15
to blin...@chromium.org, ericwi...@google.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

unread,
Apr 30, 2015, 7:17:41 AM4/30/15
to Tobi Reif, blink-dev
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

unread,
Apr 30, 2015, 7:20:57 AM4/30/15
to PhistucK, Tobi Reif, blink-dev
@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

unread,
Apr 30, 2015, 7:46:09 AM4/30/15
to blink-dev
> 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

unread,
Apr 30, 2015, 9:01:51 AM4/30/15
to v.van....@hva.nl, blink-dev

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: 

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

unread,
Apr 30, 2015, 11:39:05 AM4/30/15
to blin...@chromium.org
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

unread,
Apr 30, 2015, 1:21:33 PM4/30/15
to mile...@gmail.com, blink-dev
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

unread,
Apr 30, 2015, 2:07:36 PM4/30/15
to blin...@chromium.org
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. :-/
Message has been deleted

karen....@gmail.com

unread,
May 2, 2015, 12:34:49 AM5/2/15
to blin...@chromium.org, ericwi...@google.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

unread,
May 2, 2015, 5:23:06 AM5/2/15
to blin...@chromium.org
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?*
> <https://www.chromestatus.com/metrics/feature/timeline/popularity/501>
>

Brian Birtles

unread,
May 2, 2015, 10:36:26 PM5/2/15
to blin...@chromium.org, ericwi...@google.com
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

unread,
May 3, 2015, 11:07:12 PM5/3/15
to Brian Birtles, blink-dev, Eric Willigers
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

unread,
May 4, 2015, 6:52:52 AM5/4/15
to blin...@chromium.org
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

unread,
May 5, 2015, 1:30:37 AM5/5/15
to blink-dev
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

unread,
May 5, 2015, 6:20:40 AM5/5/15
to blin...@chromium.org
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

unread,
May 5, 2015, 2:46:38 PM5/5/15
to blin...@chromium.org, ericwi...@google.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

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

Requesting approval to remove too?

vector...@gmail.com

unread,
May 6, 2015, 12:19:20 PM5/6/15
to blin...@chromium.org, ericwi...@google.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

unread,
May 7, 2015, 5:33:31 PM5/7/15
to blin...@chromium.org, ericwi...@google.com, bbir...@mozilla.com


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

unread,
May 8, 2015, 7:48:39 AM5/8/15
to blin...@chromium.org, Dean Jackson, ericwi...@google.com, bbir...@mozilla.com
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

unread,
May 12, 2015, 7:35:43 PM5/12/15
to blin...@chromium.org, ericwi...@google.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!):
(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

unread,
May 15, 2015, 5:31:03 PM5/15/15
to blin...@chromium.org, ericwi...@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.

Joe Doll

unread,
May 15, 2015, 6:02:57 PM5/15/15
to chris...@google.com, blin...@chromium.org, ericwi...@google.com
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.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Elliott Sprehn

unread,
May 15, 2015, 9:19:25 PM5/15/15
to Chris Rhodes, blink-dev, Eric Willigers

CSS animations will have path support soon. :)

Dirk Schulze

unread,
May 18, 2015, 6:26:08 AM5/18/15
to Elliott Sprehn, Chris Rhodes, blink-dev, Eric Willigers
On May 16, 2015, at 3:19 AM, 'Elliott Sprehn' via blink-dev <blin...@chromium.org> wrote:

CSS animations will have path support soon. :)

Animation along a path you mean. Not animated paths per se. Maybe Chris can share some details but from what I saw visually (didn’t look at the source code) the paths are animated.

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

Chris, why can’t you rely on scripted animations? The animations are probably event triggered so you are probably are not talking about SVGs as images.

Greetings,
Dirk

Dirk Schulze

unread,
May 18, 2015, 6:30:05 AM5/18/15
to Joe Doll, chris...@google.com, blin...@chromium.org, ericwi...@google.com
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.

You are probably talking about <set> then. These tags belong to SMIL and would be deprecated as well.

CSS Animations/Transitions will support discrete animations of properties that are not animatable in the future. Which attributes/properties do you need to set? Many more SVG attributes are in the process of getting transformed to so called presentation attributes and will be configureable with CSS as well.

Greetings,
Dirk

Chris Rhodes

unread,
May 18, 2015, 1:13:16 PM5/18/15
to Dirk Schulze, Joe Doll, blin...@chromium.org, ericwi...@google.com
We animate the 'd' parameter of a <path> tag so that we can morph a Play icon into a Pause icon. This effect can be recreated in Javascript by simply rewriting the <svg> but we've seen a dramatic improvement in performance by using SMIL (fewer re-layouts)
--

Chris Rhodes

Elliott Sprehn

unread,
May 18, 2015, 7:20:05 PM5/18/15
to Chris Rhodes, Dirk Schulze, Joe Doll, blink-dev, Eric Willigers
Could you file a bug (crbug.com) with a test case using JS and using SMIL? We should track the performance of this use case and see how we can address it for you. I'd love to look at it in a profiler.

Joe Doll

unread,
May 18, 2015, 9:10:11 PM5/18/15
to Dirk Schulze, chris...@google.com, blin...@chromium.org, ericwi...@google.com
We usually set the "display" attribute.

Chris Harrelson

unread,
May 20, 2015, 2:37:15 PM5/20/15
to blink-dev

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.

Detailed discussion of use cases


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.

In-page SVG content


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.

SVG images


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


Tobi Reif

unread,
May 20, 2015, 2:49:29 PM5/20/15
to blin...@chromium.org
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.

Chris Harrelson

unread,
May 20, 2015, 2:52:13 PM5/20/15
to Tobi Reif, blink-dev
On Wed, May 20, 2015 at 11:49 AM, Tobi Reif <to...@tobireif.com> wrote:
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.

Hi Tobi,

Yes, that is correct. Sorry if my email was unclear. We mentioned this just to note that in the non-img tag case it will be supported.

Chris
 


Tobi

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

Brian Birtles

unread,
May 20, 2015, 8:19:35 PM5/20/15
to blin...@chromium.org
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.

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

Thanks for looking into these.

Another gap we need to address is the display property. A common pattern
is to fade out an element, then set display:none. We've found
significant performance improvements in the Parapara animation project
by using this effect to free up resources for characters while they are
off-stage.[1]

SMIL lets you set the display property in a time-based fashion whilst
CSS does not (doing this in CSS would be problematic because setting
display:none from an animation could terminate the very animation that
sets it[2]).

I'm a little less optimistic about these gaps being filled soon. We
don't even have a spec for animating path data, for example, and it's
going to be a while before we have that implemented interoperably once
we do. Likewise for additive animation.

Best regards,

Brian

[1] http://parapara.mozlabs.jp/ (e.g.
https://github.com/mozilla/parapara/blob/master/wall/public/designs/world-pictures/wall.svg?short_path=1192a9c#L105,
https://github.com/mozilla/parapara/blob/master/wall/public/designs/space/wall.svg?short_path=dffd04d#L44)
[2] http://dev.w3.org/csswg/css-animations/#animations (see the part on
display:none)

adri...@microsoft.com

unread,
May 22, 2015, 3:51:30 PM5/22/15
to blin...@chromium.org
On Wednesday, May 20, 2015 at 5:19:35 PM UTC-7, Brian Birtles wrote:
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.

We are open to the idea of a JS implementation if it becomes absolutely
necessary. However, we'd prefer to see SMIL in browsers go away and
not have to support it and today we don't currently have a plan to implement
SMIL (with JS or natively). We support the intent to deprecate.

Adrian.


Tobi Reif

unread,
May 23, 2015, 5:37:45 AM5/23/15
to blin...@chromium.org
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)

Tobi

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

adri...@microsoft.com

unread,
May 23, 2015, 10:20:23 AM5/23/15
to blin...@chromium.org, to...@tobireif.com
On Saturday, May 23, 2015 at 2:37:45 AM UTC-7, Tobi Reif wrote:
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)

Yes, we call this "internal JavaScript" and we used this approach as part
of our XPath implementation described here: http://go4a.de/1dqJgxk
Chromium has a similar capability: http://www.chromium.org/blink/blink-in-js

Essentially this means the polyfill is built-in to the browser. We don't have
plans to do this for SMIL at the moment.

Adrian.

ihk...@gmail.com

unread,
May 27, 2015, 7:24:47 AM5/27/15
to blin...@chromium.org, ericwi...@google.com

stevebr...@gmail.com

unread,
Jun 5, 2015, 12:25:34 AM6/5/15
to blin...@chromium.org, ericwi...@google.com
I would be devastated in SMIL was deprecated. My application is built on SVG and SMIL overlaid with Google Maps.

Check out an example animation below using SMIL overlaid with Google Maps on my blog:


Due to the way the Google Maps Custom Overlay works I think it would be exceedingly difficult to use any of the alternative technologies discussed here to achieve the same effect.

I found and logged a number of the original SMIL bugs in WebKit which were fixed promptly to a high standard. It’s terrible to think that something that was an agreed upon W3 standard could be deprecated after being in play for so long.

All major browsers support SMIL except IE. Its possible to write a web application that doesn't target IE due to its low usage share currently. IE does however now support most of the SVG implementation.

I am currently working on a new major release of SMIL based functionality.

Please reconsider. Thank you.



Philip Rogers

unread,
Jun 5, 2015, 11:40:01 AM6/5/15
to stevebr...@gmail.com, blink-dev, Eric Willigers
Steve,

Before SMIL is removed we'll be showing a console warning so developers are aware and can prepare. MapProVision doesn't use SMIL in images so you'll be able to use a javascript version of SMIL without too much work. This will have a benefit of fixing your animations on IE which makes the web platform more consistent to end-users. An important motivation for removing SMIL is to prevent this exact situation from happening again.

Tobi Reif

unread,
Jun 5, 2015, 12:15:08 PM6/5/15
to blink-dev
Hi Philip

On 05/06/15 17:39, Philip Rogers wrote:
> you'll be able to use a javascript version of SMIL without too much
> work.

How much work it will be remains to be seen, especially regarding
complex SMIL animations using advanced features.

Will there be a flag for disabling SMIL in Chrome, so that the
polyfill(s) can be evaluated/tested? (conveniently, and in advance of
the potential removal of SMIL)

Philip Rogers

unread,
Jun 5, 2015, 1:29:53 PM6/5/15
to Tobi Reif, blink-dev
Tobi,

Sure, I'll take a look at adding a flag to disable SMIL and I will update this thread when I have more info.

Tobi Reif

unread,
Jun 5, 2015, 3:06:06 PM6/5/15
to blink-dev
Alright!

I'd prefer it if Chrome would keep on supporting SMIL (and if everyone
would encourage Microsoft to support it as well).

But if you will indeed remove SMIL support from Chrome, it would be
handy to have such a flag, in order to prepare for that day.

Tobi

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

stevebr...@gmail.com

unread,
Jun 5, 2015, 7:06:36 PM6/5/15
to blin...@chromium.org, stevebr...@gmail.com, ericwi...@google.com
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?

PhistucK

unread,
Jun 6, 2015, 2:19:21 AM6/6/15
to stevebr...@gmail.com, blink-dev, Eric Willigers