Re: SVG animations without SMIL

Brian,

I had not considered how promoting 'd' would affect implementations that
haven't supported SMIL. I wasn't able to find any spec other than SMIL
which have path interpolation so we'd be asking implementations such as IE
to implement SVG path interpolation for the first time. Because the old
syntax is on the way out, this has convinced me that promoting 'd' is not a
practical short-term solution.

Having x, y, width, height, and transform animatable in CSS across all
major browsers is still a pretty nice story for simple effects and it looks
like we will be there very soon once the spec and implementations are
updated.

On Wed, Jun 3, 2015 at 6:16 PM, Brian Birtles <bbirtles@mozilla.com> wrote:

> On 2015/06/04 3:20, Philip Rogers wrote:
>
>> For consistency with the other geometry attributes, I don't see many
>> costs to promoting 'd' as a simple string presentation attribute. The
>> proposal would be to have it work just like animating 'd' works today:
>> string -> string where the interpolation is done on the parsed
>> representation.
>>
>
> I'd prefer we don't do this. Apart from the obvious difficulties with SVG
> path syntax, the requirements for interpolating between two paths are so
> restrictive (same number and type of segments) as to make hand-authoring
> path animations almost impossible.
>
> Rather than just push this existing problem into CSS, I think we should
> design something properly.
>
> Promoting 'd' to a presentation attribute as-is may constrain the design
> space of a proper solution in an undesirable fashion. It will also require
> browsers to implement an approach to path animation that may be deprecated
> once we work out a more appropriate solution.
>
> I think we need a path animation module that allows:
>
> * Animating between a <basic-shape>, <path()>, and <url>
>   (Where, as with the Motion Path Module, the <url> can point to a
>    <path> as well as SVG's basic shapes: <circle> etc.)
> * Animating between paths with different numbers/types of segments
>   (Different types of segments are easy to handle, but for a different
>    number of segments I think you need some concept of anchor points.)
> * Animating the 'motion-path' property
>
> What do you think?
>
> Brian
>
>