Intent to deprecate: SMIL
Chris Harrelson
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
Elliott Sprehn
PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
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.http://tobireif.com
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
On 30/04/15 10:54, PhistucK wrote:> ☆*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...
>
>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.
☆PhistucKTobi Reif
Apr 30, 2015, 11:46:09 PM4/30/15Reply to authorSign in to reply to authorForwardSign in to forwardDeleteYou do not have permission to delete messages in this groupCopy linkReport messageShow original messageEither email addresses are anonymous for this group or you need the view member email addresses permission to view the original messageto blink-dev> Unfortunately, a W3C Recommendation does not necessarily translate toAnd I didn't say it would.
> excellent (or even any) browser support.
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.> ☆*PhistucK*
> 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.
>
>> <mailto:blink-dev%[email protected]>.
>
>
Tobi
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Web Dev:
ign.com <crbug.com
> <https://status.modern.ie/csstransitionsanimationsforsvgelements>
> [2] https://hacks.mozilla.org/2015/01/web-animation-tools-network-security-insights-font-inspector-improvements-and-more-firefox-developer-tools-episode-37/>
> [4]
> https://github.com/ericwilligers/svg-animation>
> [6]
> https://birtles.wordpress.com/2015/05/01/what-do-we-do-with-smil/https://twitter.com/tobireif
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.
>unread,May 6, 2015, 6:46:38 AM5/6/15Reply to authorSign in to reply to authorForwardSign in to forwardDeleteYou do not have permission to delete messages in this groupCopy linkReport messageShow original messageEither email addresses are anonymous for this group or you need the view member email addresses permission to view the original messageHold 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:We intend to deprecate SMIL animations in favor of CSS animations and Web animations.MotivationSMIL (pronounced “smile”) is a declarative animation system that pioneered animations on the web and inspired both CSS animations and Web animations. SMIL was never implemented in all major browsers which limited its use and spec development slowed after the last spec update in 2008. We would like to deprecate our SVG-specific SMIL implementation and double-down on support and tooling of integrated HTML & SVG animation models: CSS animations and Web animations.For content authors, browsers are actively improving the SVG animation experience without SMIL. Microsoft just announced CSS animation support for SVG[1] which means authors can, for the first time, create an animated SVG image that works in all major browsers. Both Chromium[2] and Firefox[3] are actively developing CSS animation and Web animation tooling which will work for SVG content too. Eric Willigers has also created a SMIL polyfill implemented entirely on the Web Animations API[5].In terms of implementation, SMIL adds significant complexity to Blink. In the past year we had two large efforts to rewrite the tear-off implementation[4] (this supports ‘live’ animated values) as well as a difficult integration with Oilpan. Deprecating SMIL will help us focus on more general animation issues.Compatibility RiskMedium-Low: Internet Explorer does not support SMIL which limited its use for critical functionality. A concern is existing SMIL communities and content authors: we will use developer outreach to minimize risks here.Alternative implementation suggestion for web developersThere are three migration strategies:1) CSS animations.2) Web animations.3) Javascript polyfills such as Eric’s SMIL polyfill based on Web animations or fakesmile.Usage information from UseCounterUsage is low but stable at 0.0403% of pageviews[6]. The top SMIL user is currently http://crbug.com/482689Requesting approval to remove too?
