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.

[Joe Doll]

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]

CSS animations will have path support soon. :)

[Dirk Schulze]

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]

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]

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]

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]

We usually set the "display" attribute.

[Chris Harrelson]

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]

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]

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]

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]

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]

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]

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]

https://inkscape.org/en/gallery/item/5701/

[stevebr...@gmail.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:

http://mapprovision.blogspot.co.nz/ 

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]

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]

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]

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]

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]

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]

Deprecation happens when something is going to be removed, Philip referred to the eventual removal (which should concern you more than the deprecation). Currently, SMIL is only deprecated.

☆PhistucK

On Sat, Jun 6, 2015 at 2:06 AM, <stevebr...@gmail.com> wrote:

Thanks for the reply. It will be a considerable amount of work to switch to one of the alternatives which may not even work with Google Maps custom overlays. I would also be concerned about the performance of the alternatives compared to the native SMIL interface. My application uses thousands of AnimateColor polyfills to achieve the thematic overlay animation effect. A lot of performance work has been done in the non-IE browsers over the last 3 years to get to the point where SMIL is currently performing very nicely. If anyone can point me to any relevant performance data on the alternatives I would be interested.

Also you seem to now be talking about removal where previously I thought we were only talking about deprecation?

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

[boxbor...@gmail.com]

https://bugzilla.mozilla.org/show_bug.cgi?id=1171966#c14

FF last version bug in SMIL 

[Philip Rogers]

A small update, we've landed the patch to show the deprecation warning: https://src.chromium.org/viewvc/blink?view=rev&revision=196823.

We're adding the flag to disable SMIL in http://crbug.com/498081. Please star that bug to get updates.

[boxbor...@gmail.com]

If thats true it would be nice to create some topic to to help with the transition from the SMIL. Is CSS can replace it completely? I have an unanswered question on the http://stackoverflow.com/questions/30965580/svg-animation-replace-to-css-effects-hover-click

I wondered that Chrome now have, 

CONSOLE WARNING: SVG's SMIL animations (<animate>, <set>, etc.) are deprecated and will be removed. Please use CSS animations or Web animations instead.
while Fire Fox is still going to support it

пятница, 12 июня 2015 г., 0:44:08 UTC+3 пользователь Philip Rogers написал:

[thomas...@gmail.com]

By "deprecating" do you mean that Chrome will still run SMIL animation but will not get any technical update per SMIL specification? I just begin learning making SMIL animation in standalone SVG but I fear that Google's decision is not sound. SMIL allows graphists to make animation without knowledge of scripting or where scripting is forbidden due to concern of security. Particularly I want to know if there's any straightforward replacement of SVG path morphing with CSS animation, but I expect there is none.

[PhistucK]

Yes, this is the meaning of "deprecating" here, along with - "it will probably be removed at some point in the near future".

☆PhistucK

On Fri, Jun 26, 2015 at 7:22 PM, <thomas...@gmail.com> wrote:

By "deprecating" do you mean that Chrome will still run SMIL animation but will not get any technical update per SMIL specification? I just begin learning making SMIL animation in standalone SVG but I fear that Google's decision is not sound. SMIL allows graphists to make animation without knowledge of scripting or where scripting is forbidden due to concern of security. Particularly I want to know if there's any straightforward replacement of SVG path morphing with CSS animation, but I expect there is none.

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

[ola.foshe...@gmail.com]

On Wednesday, 29 April 2015 23:09:31 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.

What would take me 10 minutes to get right when scripting I can do it in 10 seconds with SMIL, like nested animations. SMIL is good for rapid prototyping. Removing SMIL also removes any incentive for SVG-editors to improve their animation support.  If the alternative is to spew out javascript animation code then editors might as well generate WebGL + asm.js… Which is the death of W3C markup ideals.

Allowing Microsoft to dictate what you support is a very bad strategy. This means developers will go back to implementing for IE first and fudge it to work with Chrome. I currently do it for Chrome first and then fudge it for IE. I also ask customers to standardize on Chrome for internal apps under the assumption that you don't break apps by trashing W3C standards. So now Firefox looks more attractive for intra-net applications.

If you are going to deprecate W3C web standards because MS is sitting on the fence, then it makes no sense to use Chrome as the primary target. You essentially allow IE to regain the de facto standard position a priori. Who knows, what is next standard you will throw into the trash, any attribute that IE is not going to fix? What I am getting from this is that MS is doing better than Google at backwards compatibility and that Mozilla Firefox is the only reliable platform. I never had to fix a site because of a broken Firefox release. Can't stay the same about MSIE or Chrome.

People are leaving Dart in favour of MS Typescript too. People are questioning the longevity of Polymer because of Angular 2 which puts breaks on adoption. You need to back your own stuff.

The perceived lack of stability of the Google universe is poison because it is very expensive for developers.

[PhistucK]

You seem to have taken the "Internet Explorer does not intend to implement SMIL" as a larger argument than it is.
- SMIL is very little used.

- SMIL adds major complexity to the engine.

- Most of SMIL can be implemented using other technologies.

Those are the prominent arguments.

And for your information, Internet Explorer (and Edge) breaks backwards compatibility just as well as Chrome, if not more (VBScript, VML, XML Data Islands and data bindings, attachEvent and the list goes on). The only difference is that Internet Explorer implements a multiple engine strategy (which is deprecated now and was never advised to be used long term) that lets you load an older engine, deprived of speed, advances, fixes, standards compatibility and new features. Edge does not have the older engines anymore, so it also breaks backwards compatibility.

And if you have not been bitten by a broken Firefox release, you are either lucky, or you just did not notice. It happens to all of the browsers. The nature of human error.

☆PhistucK

[ola.foshe...@gmail.com]

On Sunday, 16 August 2015 08:25:29 UTC+2, PhistucK wrote:

You seem to have taken the "Internet Explorer does not intend to implement SMIL" as a larger argument than it is.
- SMIL is very little used.

Define very little. A percentage says nothing, but the total number of developer hours to replace it globally.

Even then it does not matter, because it is a trust issue. It is a matter of picking stable technologies when you start on a project. That is the purpose of having standards and following them. Mozilla has a good track record for following standards, Google to some extent, Microsoft not so much…

- SMIL adds major complexity to the engine.

- Most of SMIL can be implemented using other technologies.

Those are the prominent arguments.

I don't see why SMIL adds major complexity to the engine if you can implement it using other technologies over the same engine, but it does not matter. SMIL is semantic markup. CSS isn't. The premise for WWW browsers is semantic markup, not an application API. If browsers turn into application APIs, then they will be replaced with something else.

CSS animations are sloppy (percentage based) and inflexible and still not a standard, and neither are web animations. So the only replacement for SMIL is CSS-transitions + javascript which are crude and annoying.

And for your information, Internet Explorer (and Edge) breaks backwards compatibility just as well as Chrome,

if not more (VBScript, VML, XML Data Islands and data bindings, attachEvent and the list goes on). The only difference is that Internet Explorer implements a multiple engine strategy (which is deprecated now and was never advised to be used long term) that lets you load an older engine, deprived of speed, advances, fixes, standards compatibility and new features. Edge does not have the older engines anymore, so it also breaks backwards compatibility.

Well, that's a pity, header "x-ua-compatible" is used quite frequently to get stability. If IE does not support it businesses will simply not upgrade.

And if you have not been bitten by a broken Firefox release, you are either lucky, or you just did not notice. It happens to all of the browsers. The nature of human 

error.

Not human error, just bad development process. Chrome has twice shipped with a serious bug triggered by web fonts that made the webpage completely invisible, that's not an insignificant glitch. It's a disaster. Chrome's render engine is spuriously jerky with no tracking in the performance profiler.

I like Chrome better than Firefox as an end user, but objectively, Mozilla is currently doing a better job. So essentially, Firefox is starting to look like the better alternative for intra-net applications.

[ola.foshe...@gmail.com]

On Sunday, 16 August 2015 09:57:51 UTC+2, ola.foshe...@gmail.com wrote:

On Sunday, 16 August 2015 08:25:29 UTC+2, PhistucK wrote:

You seem to have taken the "Internet Explorer does not intend to implement SMIL" as a larger argument than it is.
- SMIL is very little used.

Define very little. A percentage says nothing, but the total number of developer hours to replace it globally.

Just to get a perspective at this: The current tracker at https://www.chromestatus.com/metrics/feature/timeline/popularity/501 reports 0.59% usage, the number quoted on top is 0.0403%

There are allegedly ~ 5*10^8 active websites in the world. Let's be kind and assume it takes 1 hour to fix a SMIL using website on average, and that people are willing to work 240*8 hours per year, then we get:

0.000403*(5*10**8)/(240*8) ≈105 man years to replace SMIL.

0.0059*(5*10^8)/(240*8) ≈ 1536 man years to replace SMIL.

I bet adding a compatibility layer for SMIL is measured in months…

Social responsibility… ;^)

[Tobi Reif]

On 17/08/15 10:59, ola.foshe...@gmail.com wrote:
[...]

> Just to get a perspective at this: The current tracker
> at https://www.chromestatus.com/metrics/feature/timeline/popularity/501
> reports 0.59% usage, the number quoted on top is 0.0403%
>
> There are allegedly ~ 5*10^8 active websites in the world. Let's be kind
> and assume it takes 1 hour to fix a SMIL using website on average, and
> that people are willing to work 240*8 hours per year, then we get:
>
> 0.000403*(5*10**8)/(240*8) ≈105 man years to replace SMIL.
>
> 0.0059*(5*10^8)/(240*8) ≈ 1536 man years to replace SMIL.
>
> I bet adding a compatibility layer for SMIL is measured in months…
>
> Social responsibility… ;^)

And 1 hour is very optimistic.

Making sure that a complex SMIL animation works correctly after dropping
in a polyfill by a project which hasn't published any release yet (
https://github.com/ericwilligers/svg-animation/ ) could take between 10
minutes and 10 hours.

[PhistucK]

That is an irrelevant calculation. The percentage is of the number of page views, not the number of sites. There may be 100 sites that use it in all of their pages and the number goes up in an instant.

For example, YouTube, used SMIL to their new video player, released a few weeks ago. I reckon this will increase the percentage (or already increased it), but it is a single player that will fix countless pages (any embedded video included).

This is probably why the number has increased.

☆PhistucK

[Tobi Reif]

On 16/08/15 08:24, PhistucK wrote:
> - SMIL adds major complexity to the engine.

Is that a problem for you?

[PhistucK]

1. It is a problem for the Chrome team, because it makes them write less code, because of the consequences of their changes, as part of the high code complexity.

2. It is a problem for Chrome users, because less code means less fixes and features (and perhaps less bugs, right :) though also more bugs, also due to the complexity).

So, yes, it is a problem for everyone, basically.

☆PhistucK

[Tobi Reif]

On 17/08/15 13:49, PhistucK wrote:
> 1. It is a problem for the Chrome team, because it makes them write
> less code, because of the consequences of their changes, as part of
> the high code complexity.

So this part is not a problem for you. Great!

The Chrome team doesn't have any problem representing/communicating its
objectives, I think :)

The Chrome team are the right people to weigh they pros and cons
affecting the Chrome team, IMHO.

> 2. It is a problem for Chrome users, because less code means less
> fixes and features (and perhaps less bugs, right :) though also more
> bugs, also due to the complexity).

They could keep the SMIL code and ensure to have sufficient manpower
(which would save existing users of SMIL potentially many many more hours).

Related: The current implementation of SMIL in Chrome works quite well,
for my purposes.

> So, yes, it is a problem for everyone, basically.

It is not a problem for me.

But the planned decision by Google / the Chrome/Chromium team to break
all SMIL animations represents a problem for me - I've already spent
many hours creating SMIl animations, and I might soon have to invest
more hours just to keep them running in Chrome.

Anyone who thinks it will take just a few minutes to drop in the
polyfill and to ensure that everything runs correctly is welcome to
donate these few minutes :)

Things change, more stuff will be deprecated - but I would indeed prefer
it, for reasons affecting me directly, if all popular browsers would
finish supporting SMIL before deprecating it. Deprecation can happen
much later or ideally never.

I'm not breaking Google's stuff, and I'd appreciate it if they won't
break mine :) at least for many more years.

[PhistucK]

From the intent -

"In terms of implementation, SMIL adds significant complexity to Blink"

>if all popular browsers would finish supporting SMIL before deprecating it

What? Finishing its support and then deprecate it? That does not make any sense.

Since not many websites use SMIL and it adds complexity (and security issues that negatively affect everyone) and since Google apparently does not see this feature as a high priority (to say the least, apparently), it will not invest in perfecting and maintaining it (which may take a lot of time), but instead invest in dropping it (which is apparently much easier). This is just sensible. You may not agree with the prioritization. The numbers tell a different story.

While having less new fixes and features is not a problem for you, you are the minority of the users. Users want a faster browser and one that does not crash or leave them vulnerable. Developers want easier ways to develop stuff (CSS features, bug fixes) and new ways to interact (NFC, Bluetooth and other new APIs). Just because you do not need those things, it does not mean they are not much more important to the rest of the developers (and users). You are the minority - a vocal minority, but a minority.

☆PhistucK

[ola.foshe...@gmail.com]

On Monday, 17 August 2015 13:31:23 UTC+2, PhistucK wrote:

That is an irrelevant calculation. The percentage is of the number of page views, not the number of sites. There may be 100 sites that use it in all of their pages and the number goes up in an instant.

For example, YouTube, used SMIL to their new video player, released a few weeks ago. I reckon this will increase the percentage (or already increased it), but it is a single player that will fix countless pages (any embedded video included).

This is probably why the number has increased.

So you are basically saying that the representativity of their sampling method is fundamentally flawed. Good to know.

[PhistucK]

Why is it flawed? Page views matter more than the number of websites. If you have a website that uses SMIL on one of its pages but no one visits that page, it should not be counted towards the use counter of SVG, as is it unused by users.

The system is not trying to find websites that use SMIL, it is trying to detect the usage of the feature that users experience.

Also, the count may be even more elaborate than that (but it does not count websites, I am pretty sure). I do not remember the exact method, sorry.

☆PhistucK

[ola.foshe...@gmail.com]

On Monday, 17 August 2015 18:43:06 UTC+2, PhistucK wrote:

Why is it flawed? Page views matter more than the number of websites. If you have a website that uses SMIL on one of its pages but no one visits that page, it should not be counted towards the use counter of SVG, as is it unused by users.

So what you are saying is that educational sites that use SMIL are less important than porn sites that use SMIL. Not to mention intra-net sites, which are completely unimportant by this fundamentally flawed metric. According to this "page view metric" the HasAttribute DOM function should be removed and many others along with it... Why stop at SMIL? Let every browser vendor destroy some random technology because it is only used on 10.000.000 websites and watch the web deteriorate.

 

The system is not trying to find websites that use SMIL, it is trying to detect the usage of the feature that users experience.

Also, the count may be even more elaborate than that (but it does not count websites, I am pretty sure). I do not remember the exact method, sorry.

No, if you increase the sample size you will mitigate these issues. Unless you are saying that smaller sites are less likely to use SMIL.

---

Anyhow, to summarize:

1. There are no good arguments for undermining declarative animation. Movement of objects are semantical, not presentational. If SMIL needs fixing, fix it, but don't destroy it.

2. Scripts are woefully inadequate and dangerous as data (user uploads and verification).

3. If you remove declarative markup from browsers, then editors are not going to support it. That basically means each editor will use a home-grown format.

4. Editing animation scripts are more time consuming than tweaking svg-animation-elements, not only for designers, but also for programmers.

5. It will take at least 3-5 years before we have an adequate and supported replacement technology because of the long tail.

6. Opera had well working SVG animation over 12 years ago. It can't be that hard…

7. If  Opera and Mozilla could afford to do it, then Google can afford to do it.

8. Instability is expensive for the rest of the world and Google's reputation when it comes to stability is not great. But Google do a good job with App Engine. It is nice, stable and don't change much. I guess the key difference is that on App Engine Google actually have developers as customers...

[PhistucK]

Inline.

☆PhistucK

On Mon, Aug 17, 2015 at 9:14 PM, <ola.foshe...@gmail.com> wrote:

On Monday, 17 August 2015 18:43:06 UTC+2, PhistucK wrote:

Why is it flawed? Page views matter more than the number of websites. If you have a website that uses SMIL on one of its pages but no one visits that page, it should not be counted towards the use counter of SVG, as is it unused by users.

So what you are saying is that educational sites that use SMIL are less important than porn sites that use SMIL. Not to mention intra-net sites, which are completely unimportant by this fundamentally flawed metric. According to this "page view metric" the HasAttribute DOM function should be removed and many others along with it... Why stop at SMIL? Let every browser vendor destroy some random technology because it is only used on 10.000.000 websites and watch the web deteriorate.

If users visit pages that use a feature, it matters. If a website that uses a feature is out there but users do not visit it, users are not hurt by the loss of the feature. This is the point of the counters, to make sure no one (or relatively "no one") is hurt by the loss of a feature. Of course, the ratio changes according to the cost of maintaining a feature. A relatively costly feature like showModalDialog does not require an extremely low percentage (but still low), while a "free" feature like a simple constant (offscreenBuffering, for example) needs an extremely low percentage in order to be removed.

If you have a better (sensitive to privacy and not intrusive) way of counting the usage, you may suggest it in a new thread.

As a side note - how would Chrome distinguish a website? Some domains host millions of "websites" (Geocities and Tripod back in the day, but I am sure there are modern equivalents that do not use subdomains, but paths). Some websites have several sub domains - but all of them belong to the same website - how would Chrome know that?

 

 

The system is not trying to find websites that use SMIL, it is trying to detect the usage of the feature that users experience.

Also, the count may be even more elaborate than that (but it does not count websites, I am pretty sure). I do not remember the exact method, sorry.

No, if you increase the sample size you will mitigate these issues. Unless you are saying that smaller sites are less likely to use SMIL. 

---

Anyhow, to summarize:

1. There are no good arguments for undermining declarative animation. Movement of objects are semantical, not presentational. If SMIL needs fixing, fix it, but don't destroy it.

2. Scripts are woefully inadequate and dangerous as data (user uploads and verification).

3. If you remove declarative markup from browsers, then editors are not going to support it. That basically means each editor will use a home-grown format.

4. Editing animation scripts are more time consuming than tweaking svg-animation-elements, not only for designers, but also for programmers.

5. It will take at least 3-5 years before we have an adequate and supported replacement technology because of the long tail.

6. Opera had well working SVG animation over 12 years ago. It can't be that hard…

7. If  Opera and Mozilla could afford to do it, then Google can afford to do it.

8. Instability is expensive for the rest of the world and Google's reputation when it comes to stability is not great. But Google do a good job with App Engine. It is nice, stable and don't change much. I guess the key difference is that on App Engine Google actually have developers as customers...

[ola.foshe...@gmail.com]

On Monday, 17 August 2015 22:23:16 UTC+2, PhistucK wrote:

If users visit pages that use a feature, it matters. If a website that uses a feature is out there but users do not visit it, users are not hurt by the loss of the feature. This is the point of the counters, to make sure no one (or relatively "no one") is hurt by the loss of a feature.

None, except millions of people. Essentially anyone who wants to create engaging content aiming at the educational sector for a low cost for a start. Like primary school.

 

Of course, the ratio changes according to the cost of maintaining a feature. A relatively costly feature like showModalDialog does not require an extremely low percentage (but still low), while a "free" feature like a simple constant (offscreenBuffering, for example) needs an extremely low percentage in order to be removed.

If you have a better (sensitive to privacy and not intrusive) way of counting the usage, you may suggest it in a new thread.

Are you a moderator of the thread? How about this:

1. Work with a standard body.

2. Implement the _full_ standard when it is ready.

3. Stick with it.

4. Improve it.

5. Show that you know where you are heading.

6. Don't be whimsical after deployment.

7. Don't leverage your market dominance to subvert standards. It will get back at you.

Google is very self contradictory when claiming that declarative content is out in Chrome, but on the other hand pushing hard for declarative content through shadow-DOM and Polymer. So where are Google going? Where is the direction? In the direction of MS. MS have been opposed to animation beyond scripting since forever, so they are actually consistent. Annoying and mostly damaging to the web, but consistent.

SVG+SMIL is an enabler. SMIL is important for generating educational content and it goes way beyond SVG. The intent behind SMIL was to synchronize different media to time, e.g. SMTP etc. Scripting is no substitute for it, and neither are web animation apis. Improving on it until it actually is suitable for tying together content would be the right thing to do.

I am sure implementing SMIL is not-fun, but I would hope that it is the managers that make decisions about the overall direction and not the engineers that do the implementation.

Google has the power to destroy SMIL and limit SVG, but it is wrong for them to do so. It pushes developers over to non-semantic content like canvas2D and webGL.

[Joe Doll]

I'm impacted with the deprecation of SMIL, because I use it on many of my pages. Yet, I think SMIL should be changed to add a level of abstraction between the SVG and user code.

In my case, I would auto-generated tens of thousands of lines of SVG for every file, and then I would run a generic SMIL animation engine. Yet the SMIL implementation, was different for every browser, and it would change as the browsers were updated. SMIL is not a full spec. It might be about 33% specified.

I had to change from SMIL animation to javascript animation, because SMIL wasn't getting it done. The javascript worked the same on all browsers, and it ran more smoothly than SMIL. The same javascript was used for all animations, so the javascript was more or less a form of SMIL. Of course, I only implemented the things I needed, but it performed better than SMIL. I implemented generic scaling, translation, and rotation.

If I can replace SMIL with javascript with a few weeks of programming (not sure I spent that much time), then SMIL needs a lower level of implementation that is in addition to what it intends to do. In other words, SMIL should be implemented with an intermediate language such as javascript. In that way, the SMIL can be taken over by the SMIL enthusiasts.

This is possible to make standard without a committee, because the javascript is in the content of the file. In addition, SVG is XML, XML allows you to create tags.

In other words, SMIL can live and thrive, if a javascript engine is stuck into a file (or on the server) where SMIL is used inside of the SVG.

My SMIL interpreted by javascript is only 500 lines of javascript, but as I said, it is not a full implementation. It is a better implementation in that it works better.

This might be a way for everyone to go home happy.

[PhistucK]

Advocates do not like a JavaScript implementation (and rightfully so), because the problem with a JavaScript implementation is that you cannot use JavaScript within <img> and similar, but only when you embed it as an iFrame or similar.

☆PhistucK

[ola.foshe...@gmail.com]

On Tuesday, 18 August 2015 02:15:31 UTC+2, Joe Doll wrote:

In other words, SMIL can live and thrive, if a javascript engine is stuck into a file (or on the server) where SMIL is used inside of the SVG.

My SMIL interpreted by javascript is only 500 lines of javascript, but as I said, it is not a full implementation. It is a better implementation in that it works better.

This might be a way for everyone to go home happy.

I understand your thinking and appreciate that this will work for some situations where you control the content. The key problem I see is that it is very difficult to establish a XML-markup standard for timed content/animation without a widely distributed implementation to drive it. Just look at what happened with VRML and the successors for 3D markup. Lots of specification work, no widely distributed player.

I am also not too happy with complicated external poly-fills in general because they tend to have a maintenance cost, debugging costs, performance costs, make performance tuning harder and they also have to be vetted for security reasons.

If SMIL is canned I think I will just switch to canvas2D/WebGL for scripted animation.

[Joe Doll]

I disagree that is much of a limitation, because precious few websites allow SVG front-end uploads. So the SVG content is placed on the website by the author of the website who has a lot of options.

[tbyrn...@gmail.com]

I am the author of the Flash2Svg tool and I think that SMIL has not really had the tooling to see wide spread adoption.

Here is an example of a full cartoon published in SVG/SMIL, I think there's a lot more to explore in this technology.

While this is achievable in Web Animation I personally think that a markup approach is better for many reasons (most of which have been touched on in this thread).

On Thursday, 30 April 2015 07:09:31 UTC+10, 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?

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

[Tobi Reif]

The SVG spec says this regarding conformance:

http://www.w3.org/TR/SVG/conform.html#ConformingSVGViewers
:
"Dynamic document content can be achieved via declarative animation or
by scripts modifying the SVG DOM.)"

SVG2:
http://www.w3.org/TR/SVG2/conform.html#ConformingSVGViewers
:
"Dynamic document content can be achieved via declarative animation or
by scripts modifying the SVG DOM."

[fab...@gmail.com]

Hi. I just want to chime in here and say that I have discovered the joys of SVG only in the last year or so. SMIL might be old to some, but it's new to me. Data showing that it is not gaining popularity might be skewed by a history where SVG didn't have much support in browsers in the first place, and it took a while for us silly front-end folks to realize that exploiting web fonts for vector web graphics was more trouble than it's worth.

Anyway, I haven't used much SMIL yet, but *I planned to in the near future*. I just wanted to add my voice to the soup here. I'm well aware of all the plans to make a polyfill, and that there is forward movement on this decision whether or not a little guy like me says something or not. But I thought I'd try anyway.

[Cyril Concolato]

I think it is a mistake to deprecate entirely SVG/SMIL animations. I understand the need to limit the amount of code in a browser to reduce the number of bugs, the security issues ... However, I think there are simplifications that can be done to reduce the code size of SVG animation in the browser, without requiring a full deprecation.

The first simplification is regarding SMIL. SMIL is complex, and offers too many features that can't be implemented interoperably realistically. However, most authors don't need the full complexity of SMIL to use SVG animations. For instance, a single 'animate' element could be used instead of having animateColor, animateMotion, animateTransform ... That would reduce the animation footprint in the browser. The complex animation sandwich model [1] could be dropped as well. In many cases you don't need DOM/CSS/animations interactions. The complex interval management too [2] could be simplified, for instance if you limit animations to start only once at given times, not on events, leaving event-based animations to CSS. The syncbase part could also be simplified to make its implementation easier. A second problem is the DOM as other people mentioned. Again, I don't think most animation authors need the current complex SVG DOM. If they need the DOM, they'll use frameworks like snap.

SVG animations' strength is that it is declarative. This means, as other people said, that you can run them in script-less environments, that designers can author them without having to code. It means also that in an implementation, you can easily look ahead in the animations and preload/optimize. The difference is the same as using the <picture> element or srcset to do responsive images versus using JavaScript. I think such optimizations have not been studied for SVG animations because the above complexities, but if the above simplifications were made, I think the SVG animation code could be simple and efficient. A good replacement of animated GIFs or PNGs in many cases.

JavaScript as an animation technology (and as such polyfills) is good for some use cases such as data visualization, as used by D3.js, but it is not appropriate for all scenarios. As some others said, CSS is a declarative way to do animations. It is I think well suited for animations which are part of the styling of the content, for instance in UI. The play/pause morphing animation of the YouTube player is a great example of that. But the fact that the animation actually starts when the style is attached is very problematic for synchronization.

SVG animations is the only declarative tool in the Web Platform for representing animations when the animation is part of the content. A lot of examples have been posted already with cartoons, such as [3] converted from Flash and without scripts. I think this is a valid use case for keeping SVG animation declarative features in the browser as a replacement technology for Flash animations. Sure, there are tools like Swiffy or Shumway to convert/render Flash animations, but again they heavily rely on scripting. Such content cannot be described easily with CSS and even if it could, it wouldn't make sense as a style sheet! Declarative SVG animations can be also easily streamed, and synchronized with video/audio content. Some use cases are overlays on top of videos, stored in tracks, such as subtitle tracks, as discussed in the SVG Streaming draft [4].

In summary, I think the Web Platform should have a declarative tool for describing animations as part of the content. It would be a pity to deprecate the entire SVG animation module, especially if its interesting features can be implemented in the browser based on the Web Animation model as the Web Animation element [5] draft suggests. Some of its syntax should be preserved for authors, even if the internals of how it's implemented in the browser is completely modified.

[1] http://www.w3.org/TR/SMIL3/smil-animation.html#animationNS-AnimationSandwichModel

[2] http://www.w3.org/TR/SMIL3/smil-timing.html#Timing-IntervalTiming

[3] http://perso.telecom-paristech.fr/~concolat/SVG/flash4.svg

[4] https://svgwg.org/specs/streaming/

[5] https://svgwg.org/specs/animation-elements/

[emmanue...@gmail.com]

This is kinda sad. I understand that there is no great demand for SMIL, but for us as developers SMIL is a very nice animation option. I have used it before with fallback animations for browsers that don't support it.

Take this example:

With Lollipop, Android introduced a very nice animation for the hamburger menu which transforms the 3 rectangles into an arrow. Very nice looking. So I decided to clone that animation for my website's menu button using SMIL writing just a couple of lines. It runs great on both Chrome and Firefox. It lets me morph the shapes perfectly. Now, I know that specific animation could also be done using CSS matrix transformations, but they key here is that SMIL allows us to entirely transform/morph a shape by its points --for example allowing us to morph a star into a triangle or a square into a circle-- and not only by distorting it.

I did some research and found the Raphael JS library which accomplishes this (actually changing SVG points). But now, as a developer, I don't want to have to use even more libraries for my website to work. Raphael Library would add 90Kb of JS. Also, either using an external library or CSS transformations (when they can achieve the desired animation) would require many more lines of code, while using SMIL is as simple as this: <animate from="xxx" to="yyy" attributeName="points">

Chrome warned me (in the console) that SMIL is deprecated and WILL be removed. So, if this is true and it gets removed, is there any alternative to morph a shape into another without using complex javascript?

[emmanue...@gmail.com]

Impressive example! It renders very very well without any frame drop for me. I use SMIL for much simpler things, but here is another reason to still support it and even give it a push to widen its adoption. Also, 1.4MB gzipped is pretty decent for a cartoon with such complex animations and sounds.

[mark...@gmail.com]

I am disappointed in this decision, I've been using SMIL embedded in SVG via the <img> tag to produce animated artwork and share on a social platform (ello) for about a year.

After reading this thread and investigating the limitations of CSS animation I don't believe it's possible to reproduce any of the SVGs that I have created using embedded CSS.

I do understand that I am an edge use case, but I am nonetheless affected.

Here is a selection of my animated SVGs that display well on Chrome and Firefox: http://punchafoo.com/svg/

Thank you,
Mark

[Tobi Reif]

Nice SVG SMIL animations! I especially like this one
http://punchafoo.com/svg/icecube5.svg

Tobi

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

On 2015-09-19 00:23, mark...@gmail.com wrote:
> I am disappointed in this decision, I've been using SMIL embedded in SVG
> via the <img> tag to produce animated artwork and share on a social
> platform (ello) for about a year.
>
> After reading this thread and investigating the limitations of CSS

> animation I don't believe it's possible to reproduce _any _of the SVGs

[iamcraig...@gmail.com]

I wanted to just chime in on this thread that I too think it is a mistake to remove SVG SMIL animations. I think they weren't really given a fair chance to be widely utilized on the web as can be seen by the big spike in usage after Chrome decided to deprecate them:

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

I have a feeling their usage would continue to climb.

There are a number of places where they make more sense than CSS animations and animated GIFs. As far as ease of development, throwing an animated SVG into an image tag or embedding inline SVG is far simpler than having to use custom markup/css/javascript to achieve the same effect.

Animated GIFs will still work for this purpose, but they are much larger in file size and will not scale without losing quality.

Developers are lazy, and I think by removing this feature it will lead to more people using animated GIF where they were once using SVG rather than taking the time to convert their SVGs into CSS animations.  

I was using some SVG preload animations, and it took me HOURS to convert them to CSS animations that would work across platforms. The SVGs worked the first time, but when using masks with CSS animations I ran into a number of cross browser inconsistencies.

Craig

[PhistucK]

On Sun, Sep 20, 2015 at 7:38 PM, <iamcraig...@gmail.com> wrote:

I think they weren't really given a fair chance to be widely utilized on the web as can be seen by the big spike in usage after Chrome decided to deprecate them:

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

I have a feeling their usage would continue to climb.

It looks like the usage only climbs because the new YouTube ​player is using it. Once they remove their usage, it would go back to next to nothing. :(

☆PhistucK

[Thomash Lee]

Whatever the reason behind the usage climb, Google still fails to offer us a substitute of SVG path data animation without script. This function alone is enough to continue SMIL.

[PhistucK]

Generally, it is not enough, if the usage is so low.

But I know the direction is to generally add the missing parts.

☆PhistucK

[a.sara....@gmail.com]

I've been using SVG and SMIL recently and was planning to keep on using it from now on. What sold me on it was the ability of using Flash2SVG to create animations in Flash (proprietary) using a timeline, and export them to SVG. Visual authoring tools to create animations in CSS aren't great, and the time it takes to create them by hand is prohibitive. The added bonus of using SVG/SMIL is that the animation will fallback to a static frame for browsers that do not support it - IE, Edge. Yes, there is the need, as with CSS animations, to provide fallbacks to browsers that do not support SVG (IE9 and below, Android 2) but I feel that depending on the project's target this might not even be a consideration.

SVG and SMIL are neat self contained files that can just be dropped on the page. They do require external JavaScript for animation but so do (or might) animations made with CSS. They are a realistic alternative to GIFs and as far as I'm aware they're the only sane option for having animations with morphing paths.

In the absence of good authoring tools to create semi-complex CSS animations most designers/developers won't do it. There is no time or budget to be spent on a project - a regular project for a client with a small business - creating animations by hand. This has to be well resolved before deprecating SMIL.

Please don't remove the support, at least until there are solid, well established alternatives. It seems we're moving backwards, not forward.

[pro...@gmail.com]

There is also smil2css

[eric.k...@gmail.com]

Phillip Rodgers, 

I find it very confusing that you are saying usage rates for SMIL are low, and that the top user is ign.com. SMIL is used in YouTube's HTML5 player, so your stats must certainly be incorrect. I hope that you don't actually deprecate SMIL based on erroneous usage statistics, and break one of Google's most prominent products in the process.

[PhistucK]

When the intent first got posted, YouTube was not using SMIL by default (the new player was released to everyone a few months later).

Either way, YouTube is something Google controls, so it can drop it if needs arise, I imagine.

☆PhistucK

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

[eric.k...@gmail.com]

PhistucK,

I see what you're saying that I was commenting on old data, but doesn't this just further show the value of support for SMIL?

The team at YouTube knew that Chrome deprecated SMIL (unless none of them ever viewed the chrome console- which would be a joke), and yet they still saw enough value in the technology to intentionally include it in their new HTML5 player.

It seems like the engineers at Google aren't all on the same side on this issue. I certainly hope that the the SMIL supporters at Google (of whom there must be plenty since they used it in a recent, major product release) are explaining the value of this technology to the SMIL deprecators.

[PhistucK]

The player was implemented (long?) before SMIL got deprecated. It was released to everyone around the time the deprecation warning actually started showing up in the console.

☆PhistucK

[Chris Rhodes]

Agreed, I created this thread because I saw the deprecation warning and we had already converted from javascript -> SMIL.

--

Chris Rhodes

[fmua...@gmail.com]

You will be forced to put SMIL support back in Chrome. 

You don't understand the difference between an INTERCHANGE FILE FORMAT and a programming language. 

SMIL is the universal interchange format for animations. 

Artists need it to be independent from the underlying code.

There are some app plugins that save the javascript code for the animation, but they are not pupular. Why?

Because if you save an animation using a "snap.svg" based plugin, you cannot use it in a "greensock" based app, for example. You animation is locked and mixed with the code. It depends on such code, and on all the libraries versions.

Only SMIL can be exchanged, because is a description file format, not a programming language.

I can read a SMIL animation data from the SVG file and import it in any app, browser based, javascript or otherwise.

And with SMIL you have the advantage of a self contained animation data file. Just an .svg file, that will reproduce everywhere (and forever, no code dependencies... a standard specification format) in the exact same way, independently from the application you are using.

Good animation apps export to SMIL. For example the Flash extension "Flash2Svg" outputs an SVG animation file defined with SMIL, no need for javascript:

https://github.com/TomByrne/Flash2Svg  

Here is an example output file of a cartoon episode exported with Flash2Svg (warning: the embedded audio track makes the download sizing 1.4 megabyte):

http://www.tbyrne.org/portfolio/smil/LoveDota.svg

Artists and animators can import this in many editing applications. They can display it on any platform, and it will work because this is data, not code.

This works because DATA MUST BE KEPT SEPARATED FROM CODE. Mixing data and code will only produce an inefficient, non standard, non future proof, non portable animation, and doomed to stop working correctly at the smallest change in the javascript libraries api it depends on.

This is why standard file formats like SMIL were created in the first place. If you know the history of the graphic industry, you know that not using a standard exchange format for graphics or animations is a sure recipe for failure and production inefficiencies.

This is why you are going to put back SMIL support. Because artists demands an animation file format. This industry needs it. Something you can share with the community, something people can create tools for, something that can be imported and exported from many different software applications used in the production pipeline.

Removing SMIL support for animations and asking people to code animations in javascript is like removing PNG and JPG support for bitmaps, and asking people to write javascript code to draw each pixel.

This was a awfully wrong choice, but I'm sure you will soon realize the stupidity of removing the support for the only standard animation file format around.

Freemen Muaddib