- From: David Dailey <ddailey@zoominternet.net>
- Date: Mon, 8 Aug 2011 20:27:11 -0400
- To: "'Dean Jackson'" <dino@apple.com>, <public-fx@w3.org>
- Cc: "'www-svg'" <www-svg@w3.org>
On 04/08/2011, at 8:03 AM, Vincent Hardy wrote: >> I suppose if we get agreement on that, then we can see what the >> difference in functionality between SVG and (extended) CSS Animations >> is, which will help us determine which of the three broad directions >> Brian outlined we should head towards. > > Since we have an action (ACTION-48 - Write up use-cases and priority list > of features to be added to css animations [on Dean Jackson - due > 2011-08-02]), I think that means we had agreement during the meeting on > that direction. Then on Friday, August 05, 2011 8:24 PM Dean Jackson replied. >That's my understanding too. I think we can start from the excellent wiki page that Brian >authored. At least, that's what I planned to do. Sounds good. There are a number of good suggestions for improving SVG animation in that wiki. As Doug Schepers points out (in his message Mon 8/8/2011 6:10 PM ) reuse of animations is one such improvement and a SMIL-like approach is natural for doing that. In my experiments with borrowing the principles of declarative animation into "declarative drawing" I noticed, based on reflecting the analogy between Time and Space back again, a lot of extensions of declarative animation that might additionally useful: 1. <animatePath> A lot like <mpath> and borrowed back from Space into Time via <replicatePath>, this would allow an animation to take not just its x, y coordinates from a path with given IRL, but to take any bivariate set of attributes from a bivariate <path>. So for example, the cx and cy of a circle might inherit their animated values from an ellipse, while its rx and ry might take them from a sinusoidal curve, and the red channel and blue channel of its fill might be specified by yet another curve. Those of you who seriously examined the <replicate> proposal and have played with <replicatePath> should instantly recognize the enhancement to the power of SVG animation that this would afford. It partially overlaps with keySplines and keyTimes but is a heck of a lot more powerful, and easier to conceptualize for the average human. I think one could perhaps deprecate keySplines and keyTimes with such a model. If multivariate data through either InkML or some other mesh format are accessible to SVG, then the control need not be limited to bivariate data as with <replicatePath>. Such will be a natural extension in the future. 2. <animateModifier> this would give the ability to retrieve the gradients, filters, clipPath, masks, and patterns associated with a given object and to animate certain attributes of those objects independent of whatever non-animated uses of those modifiers have been applied to other objects. In the case of <replicateModifier> it provides an essential tool for declarative drawing, and while one could accomplish something like it by simply making multiple copies of a given modifier, one for each thing it modifies, and then animating those there, students at least in the EU seem to have found the animation of attributes associated with objects (whether they come from modifiers or from local attributes_) to be more naturally associated, semantically, with the object that is being animated. 3. the ability to animate attributes of <animate>. On numerous occasions one finds oneself needing to dynamically vary the dur, or the values list of a given <animate>. Nesting animate tags does not seem to be allowed. One solution to this problem is to include <animate> as one of the things that <animateModifier> has access to. 4. <animateChild> I've only begun to play with this concept, but it like some of the others is based on the extrapolation of the declarative animation into declarative replication and then reflecting back. Sort of like <param> allows the reuse of values to permeate the children of a group to allow more complex instances of <use> <replicateChild> allows multiple children of a group to be simultaneously varies (over space) as the group is cloned. Analogously. <animateChild> would allow the centralization of an animate module within a single <animate> tag rather than having those strewn over the children of a fairly complex group. Among the things it could do would be to enable a numeric countdown to proceed within a text tag without recourse to script. 5. random elements. To make scenery and motion "interesting" one often wants it to be aperiodic. One way of doing this is through the declarative use of random elements. I've already called for such things more ubiquitously in SVG in my note of May 4th [1] in response to brainstorming about requested features for SVG 2. The ability to define random positions, sizes, colors and speeds of animations without recourse to script would bring expressive power to non programmers that I believe would be very well received. Incidentally, I liked the gist of what I saw in Brian's wiki, including many of the simplifications for things animated. Regards David [1] http://lists.w3.org/Archives/Public/www-svg/2011May/0022.html
Received on Tuesday, 9 August 2011 00:27:50 UTC