RE: SVG animations without SMIL

Bob Hopgood wrote 
Sent: Wednesday, June 03, 2015 7:51 AM
To: www-svg@w3.org
Subject: SVG animations without SMIL

 

Despite what some people may say, SVG geometric content is specified in SVG  primarily by the path descriptions. If area colour or line thickness, say, is part of the SVG content it will use SVG rendering attributes or CSS properties in such a way that they cannot be changed by a change in user stylesheet.

 

SVG animation when it is being used for industrial control, government statistics, algorithmic animation etc  also is SVG content including the timing of such animations.

 

While it is sensible to move the timing of simple styling transitions to CSS,  allowing the user to turn them off, it makes less sense moving SVG content to CSS.

Animating SVG content has been a core part of SVG from the early days in the life of the SVG WG. It will be an enormous loss if it gets removed especially when it is well supported in both Chrome and Firefox.

 

Having said that, we are in the middle of preparing a paper  entitled Future of SVG's Declarative Animation (http://www.bahfrah.org.uk/florence/future_svg_animations.htm) showing how styling simple SVG animations might be achieved via CSS without moving the path descriptions to CSS.

 

That paper includes a short 6 second animation which has 707 animate elements that animate path descriptions.

 

The 6-minute animation that opened the WWW24 Conference in Florence this year 

runs smoothly in  Chrome and also in Firefox most of the time.  It has 4999 animate elements most of which are animating path descriptions. 

 

It can be downloaded from

http://www.bahfrah.org.uk/florence/florence_zip.zip

or run directly from

http://www.bahfrah.org.uk/florence/playviewbox.xml

 

Significant size animations can be run smoothly in today's browsers.  Many people use SVG animations for content. It is inappropriate to control the timing of them from CSS even if it is possible. Please reconsider the plan to drop animating SVG content from SVG 2.0.

 

Hi Bob,

 

As you correctly point out SVG animation has been a core part of the spec for more than a decade, and I hope the Working Group is not seriously thinking of breaking all the content that uses it.  For one or two browsers not to follow the spec is their prerogative. Let them choose not to be standards compliant but don’t do what HTML5 did with its acid tests and change the standards to meet the performance! Just because Microsoft didn’t implement SVG for the first ten years was not a sufficient reason for the W3C to declare SVG to be dead. It is used in many contexts beyond the eyes of web spiders.  If web counts measure the appropriateness of a technology, then we should still be using HTML1.0; why else would something new be invented since there is no evidence of new things being used?  

 

As you point out in http://www.bahfrah.org.uk/florence/future_svg_animations.htm educators use SVG and have been using it probably longer than most in industry. There are people using SVG animation for teaching, and not just about web stuff, but science, meteorology, etc.  And there are books that have been teaching people how to use SVG. Breaking spec is not just about breaking content, but also about breaking inertia and people’s confidence in standards and the standards process.  Your document is well-reasoned and I hope people will take the time to look at it and think about it. 

 

A few months ago, when someone pronounced that the W3C was dumping SVG animation, we were assured that no: SVG was not being lobectomized;  fallbacks would be provided so that existing content would not break. Is that still true?

 

Some CSS folks have said on this list that not ever will certain SVG properties (href for example) be “promoted” to CSS attributes. If so, there will be lost functionality and there will be broken content if all animation is to be handled by either script or css.  I see that Brian Birtles is continuing to work on ways to bring the world of styles and serious animation together and am glad to see, that you (Bob, Paul and David) are working with him to help maintain some steadiness in the road forward.  Your suggestions seem sound and the idea of using superpath or something like that to ensure ease of reuse of path geometry seems consistent. Reuse of animation “elements” (for wont of a common term to include such modifiers), will be important, and the ease of declarative access and modification of the timing of those elements such as in <replicate> will be important as well.  

 

What I fear is a setback waiting until 

a)      CSS is specced to bring into it functionality equivalent to that of SVG/SMIL  

b)      browsers implement (at differential rates)  the new specs

c)       inconsistencies of implementations are experimented with and noted 

d)      ambiguities of the spec are clarified

e)      browser bugs are reduced to the level we currently have for SVG/SMIL.

 

That is the process that took place between SVG1.1 and the present – about 15 years. 

 

Ensuring that all functionality provided by SVG animation including animation of motion along paths, which themselves are animated by morphing and rotating etc. seems like a clear necessity.  

 

Brian, where is the best place for us to contribute to, to make sure that needs are properly assessed and that economic harm is minimized? 

 

Regards

David