W3C home > Mailing lists > Public > www-svg@w3.org > June 2015

Re: SVG animations without SMIL

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 4 Jun 2015 16:43:02 -0700
Message-ID: <CAAWBYDCb61da+Wu82NzjZYKvQ7bweDGoJJy2AaHNp8oWu19gTg@mail.gmail.com>
To: Brian Birtles <bbirtles@mozilla.com>
Cc: "www-svg@w3.org" <www-svg@w3.org>, Philip Rogers <pdr@google.com>
On Thu, Jun 4, 2015 at 4:29 PM, Brian Birtles <bbirtles@mozilla.com> wrote:
> On 2015/06/05 3:50, Tab Atkins Jr. wrote:
>> In the
>> meantime, we still can't animate paths in WebAnim, which is silly.
>
> Web Animations just uses the rules defined for interpolating the attributes
> its presented with--i.e. the matching segments behavior (which actually
> makes a bit more sense for a script API). So you can animate paths in Web
> Animations already.
>
>> Let's just promote the d attribute, come up with a property name for
>> it (not 'd'), and define the simple interpolation rules for it.  We
>> can fix path at our leisure then.
>
> What's the urgency in pushing something into CSS that is basically unusable?

Shane pointed out to me offline that WebAnim is going to be capable of
directly animating the <path d> attribute anyway - it was not clear to
me that this was planned.  Great!

However, that means we have something that can be animated in SMIL (in
the browsers it's supported) and WebAnim, but not CSS.  My argument
still stands, then - upgrading <path d> to a presentation attribute
can be done fairly trivially, even if its current behavior is annoying
and weird, and then we can work on better path syntax and
interpolation separately.  I think this is worthwhile, so we don't
hold up @keyframes-based animations while we figure out the better
solution.

~TJ
Received on Thursday, 4 June 2015 23:43:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:01 UTC