Fwd: SVG animateMotion specification clarification request

Apologies to the list - I intended this to be a reply-all, not a private
reply.

Cheers,
    -Shane

---------- Forwarded message ----------
From: Shane Stephens <shans@google.com>
Date: Tue, Mar 29, 2011 at 12:53 PM
Subject: Re: SVG animateMotion specification clarification request
To: Ken Stacey <ken@svgmaker.com>


Hi Ken,

A similar problem exists for RT * (MP * MR) * AS.  If AS involves
> translation then the apparent motion path between rotate="auto" and
> rotate="none" is also different.

 ...

If you allow animateMotion and animateTransform to be given equal status,
> then the RT * (MP * MR) * AS scenario suffers the above apparent motion path
> inconsistency.
>


This is true, although I would argue that in this case the difference is
expected, as it's the same as what happens with any other rotation transform
followed by a translation transform.

With a scheme that allows for RT * AS1 * (MP * MR) * AS2, encoded in SVG as
(roughly):

<rect transform="RT">
  <animateTransform transform="AS1"/>
  <animateMotion path="MP" rotate="auto"/>
  <animateTransform transform="AS2"/>
</rect>

there is a clear ordering of transform components reflected in the output,
and you can do useful things with both AS1 and AS2 in a way that is
intuitive and consistent with transforms elsewhere in the spec (AS1
transforms the motion path, while AS2 transforms the object that travels
along the path).

On the other hand, with the (MP * MR) * RT * AS1 * AS2 approach, the
presence of the motion path automatically causes all transforms at this
level of the DOM and at the immediate parent to transform the object that
travels along the path.



> That just leaves the specified behavior - RT * AS * (MP * MR) - as the only
> approach which yields a consistent motion path between rotate="auto" and
> rotate="none".
>
> I can't say I like that behavior or that I would use it much (combine
> animateMotion and animateTransform).  But it is consistent!
>

It's also what's currently specced :)  My order of preference is:

(1) equal status to animateMotion and animateTransform (most useful,
intuitive, maintains transform invariant, somewhat inconsistent effect of
rotate="auto")
(2) the currently specified behavior (consistent effect of rotate="auto" but
less intuitive, breaks transform invariant)

with

(3) pre-applying the animateMotion supplementalTransform  (inconsistent
effect of rotate="auto", unintuitive, breaks transform invariant) as a
distant third

Cheers,
    -Shane