Re: SMIL / element-based animation syntax [was RE: Minutes, 16 March 2015 SVG WG telcon]

On 2015/03/21 10:49, Charles Lamont wrote:
> I am also generally reassured that existing SMIL features will continue,
> however:
>
>> https://svgwg.org/specs/animation-elements/
>
> I appreciate this is an early editor's draft, but I do think deprecating
> animateTransform would lead to its eventual dropping and the breaking of
> a lot of perfectly good working content. A quick look at search results
> shows tutorials in its use as recent as Oct 2014.

Yes, I wouldn't read too much into that draft. It really just represents 
an outline at how I'd like to fix up SVG's animation features (based, in 
a large part, on resolutions for SVG2) but it's going to be a while 
before I can work on it. I suspect when I do it we'll end up with a 
level 1 spec that just matches the existing feature set (plus a few 
obvious fixes) and a level 2 spec that includes newer features (which 
will depend on demand as to whether they are implemented or not).

As for animateTransform, like animateColor, it exists for historical 
reasons (when <animate>/<set> were restricted to animating scalar 
values). Having separate elements for different data types is now 
unnecessary since <animate>/<set> can animate more than scalar values. 
By using them we can avoid introducing <setTransform> and <setColor> and 
authors don't need to switch element names and syntax when the 
attributeName changes.

The other issue with animateTransform is that it animates a single 
transform but the attribute it targets is a transform list.

> I gather there is some (abstruse?) problem with it, but can that not be
> dealt with by limitation rather than deprecation?

You're right that deprecation suggests support for the feature may be 
dropped in future. However, as always, the decision to drop a feature 
outright will depend on backwards compatibility constraints. So long as 
there is still a significant amount of content relying on 
animateTransform then it won't be possible to drop support for it.

The intention of deprecating animateTransform in that (very very early 
draft) spec, is to encourage authors to use <animate> over 
<animateTransform> once <animate> is able to animate a transform list.

Best regards,

Brian

Received on Monday, 23 March 2015 01:12:06 UTC