RE: ya' know

From: Tab Atkins Jr. 
Sent: Tuesday, June 09, 2015 2:30 PM

>I 
> want to draw a path of traversal for the center of the view port and 
> to use keyTimes (keySplines are okay, but following a curve makes a 
> lot more sense, ¿does it
> not?!!¿?) to control width and height. Once center (or better yet, 
> centroid), height and width are animated, then animating x and y 
> becomes superfluous, methinks.

It seems like you can do this with just a <g> around the content and an <animateMotion> (or CSS animation of the 'motion' property), paired with some scaling.

------------
Yes, good idea. Using the <animateMotion> to control the x-y of something would work and gives much smoother motion than can be accomplished with keySplines.  

But likewise, relying on keySplines to control height and width is clunky and imprecise. A part of the <replicate> proposal that seems to have been overlooked by the Working Group was to allow any pair of attribute values to have their magnitudes controlled by a user defined path. So, for example, while an oval's cx and cy can be positioned along an animateMotion-path, it would be nice to let its rx and ry be, as well, or the h and the l of its hsl values, or the stroke-width and red component of its stroke's rgb. An implementation of these ideas (for replicate -- the spatial companion of animate) can be seen at http://cs.sru.edu/~ddailey/svg/pathRep2JS.svg (in which the yellow curve controls cx and cy of an ellipse and the green curve controls rx and ry, in the predictable manner). The use of keySplines gives univariate control (but in a non-intuitive fashion). A drawn curve gives both intuitive and bivariate control, and to a pair of naturally allied attributes such as x and y, width and height, or saturation and lightness.

It seems that folks have agreed that SVG2 won't really be done, and that browsers won't really be SVG-compliant until animation is improved and expanded (to include less expressive text-or-decoration-only domains like HTML and CSS).  And it seems like there is, once again, discussion going on about how to do this, so perhaps now is a time to consider those various things that authors have found missing in SVG animation. Being able to declaratively change timing attributes so that "dur" and "begin" might oscillate (in a paired bivariate fashion) is. Reuse of timing parameters and curve segments, as Bob Hopgood and David Duce point out, are other key aspects of what has been missing in SVG animation. That was part of my reason for suggesting <superPath> in 2008. Lo and behold, Chris Lilley explained that an allied feature had been a part of SVG 1.2 vector effects, since, what 2003?. Being able to animate a shared boundary between two regions, just makes good sense in terms of improving run time behavior, authorial complexity, and document size. 


cheers
David

Received on Wednesday, 10 June 2015 13:03:18 UTC