RE: Dropping angle-bracket syntax for animation (see also "agenda+ SVG 2 Features and Approach"

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