Re: SVG animations without SMIL

Dirk,

The SVG path syntax is pretty difficult to use (IIRC it was designed before
gzip which is why it uses one-character commands) so I understand wanting
to improve that for the long-term. It looks like there has been quite a bit
of discussion already about new path specs.

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
wasn't able to find arguments against this in the archives. Do you have a
link to previous discussions of this?

Offline, Dirk pointed out that x, y, width, and height have already been
promoted and the spec just hasn't been updated yet.

On Tue, Jun 2, 2015 at 12:44 PM, Dirk Schulze <dschulze@adobe.com> wrote:

>
>  On Jun 2, 2015, at 8:19 PM, Philip Rogers <pdr@google.com> wrote:
>
>   Can 'd' (or some solution for paths) be made a priority for SVG2? The
> reality is that it's not possible to create an SVG path animation that
> works in major browsers today and you have large projects shipping crippled
> SVG animations to major browsers. My impression is that folks were holding
> out for a SMIL implementation in all browsers but implementations seem to
> be heading in the opposite direction.
>
>
>  SVG2 is the foundation of a more agile approach that the WG is going.
> New version shall be published earlier but have less new features. I don't
> see a reason to rush in a d property at this state. We need a clean spec
> first to improve the spec quicker later.
>
>  That said, concrete suggestions for d are welcome. There is nothing that
> should stop the discussion about it. You can start by commenting on some of
> the mentioned issues with your thoughts.
>
>  Greetings,
> Dirk
>
>
> On Tue, Jun 2, 2015 at 10:44 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>
>>
>>  On Jun 2, 2015, at 7:29 PM, Philip Rogers <pdr@google.com> wrote:
>>
>>  www-svg,
>>
>>  Animating SVG content without SMIL can be difficult and I'd like kick
>> off a discussion on how to improve it. This recently came up because IE
>> does not have plans to support SMIL and Blink is moving towards removing
>> support as well.
>>
>>  Two projects at Google switched from SMIL to CSS animations and an
>> issue we hit was that useful graphics attributes such as 'd' are not yet
>> presentation attributes. Only attributes promoted to presentation
>> attributes can be animated with CSS. Would it be possible to have even more
>> attributes become presentation attributes in SVG2? Making 'd' and
>> 'transform' presentation attributes has been discussed before but seems to
>> have petered out. For folks not familiar with CSS animations, I created a
>> small demo showing how they work: http://philiprogers.com/smilandcss.html
>>
>>
>>  The CSS Transforms spec is now responsible for defining transform.
>> `transform` is indeed a presentation attribute today. And partly
>> implemented that way in WebKit and Blink already.
>>
>>  For the `d` attribute there was a discussion about the property name.
>> (d is not very descriptive.) There were also concerns about the semantic of
>> such a property. Should the value be a string? Should the value be path
>> functions as we have them for clip-path? E.g path(“M100,100….”), polygon(),
>> inset(), circle()? And I think there were even concerns about animating the
>> string.
>>
>>  Anyway, d as CSS property is not off of the table. Just not a priority
>> for the SVG 2 specification.
>>
>>  Greetings,
>> Dirk
>>
>>
>>  A second set of issues is the feature gap between web animations / css
>> animations and SMIL. These are probably best addressed in www-syle but they
>> are worth pointing out; Brian outlined a number of these in
>> https://birtles.wordpress.com/2015/05/01/what-do-we-do-with-smil.
>>
>>
>>
>