W3C home > Mailing lists > Public > www-svg@w3.org > October 2010

Re: <animateMotion> specification clarification

From: Alex Danilo <alex@abbra.com>
Date: Tue, 12 Oct 2010 18:39:45 +1000
Message-Id: <9E56AL.ACKQR3BKETXL@abbra.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: Nikolas Zimmermann <zimmermann@physik.rwth-aachen.de>, Shane Stephens <shans@google.com>, www-svg@w3.org
Hi Cam,

--Original Message--:
>Alex Danilo:
>> > The animateMotion should be applied to the parent element which in
>> > that case is the <svg>. Since that's a container element all the
>> > content should have the animateMotion applied. So the example is OK.
>Nikolas Zimmermann:
>> Hehe, now that was stupid, I should have had my coffee before
>> mailing :-)
>> But I'm still questioning wheter it's valid as SVGSVGElement is not
>> SVGTransformable, but only SVGLocatable.
>> So shall it be possible to apply transforms to SVG using SMIL
>> animations, but not through <svg transform=".."
>The spec does state in
>that <svg> is a valid target of <animateMotion>.  Whether it makes sense
>for <svg> elements not to be transformable is something I’ve wondered
>for a while.

Very good point.
Something for the WG to argue. I'd say child <svg>'s should be transformable since
that is far more likely to be useful to content authors. You could use an <image> and
reference the child SVG that way and it would transform, so the restriction on <svg>
should never be needed since you can rotate it too.

So if you can apply current scale, translation and current rotation to the root SVG
via the DOM there doesn't seem to be a good argument to limit the transform for
child <svg> does it?
Or am I missing something?


>Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 12 October 2010 08:40:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:28 UTC