- From: Alex Danilo <alex@abbra.com>
- Date: Tue, 12 Oct 2010 18:39:45 +1000
- 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 >http://www.w3.org/TR/SVG/animate.html#AnimationAttributesAndProperties >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? Alex >-- >Cameron McCormack ≝ http://mcc.id.au/ > > >
Received on Tuesday, 12 October 2010 08:40:43 UTC