Re: SVG animations without SMIL

On 2015/06/04 5:52, David Dailey wrote:
> A few months ago, when someone pronounced that the W3C was dumping SVG
> animation, we were assured that no: SVG was not being lobectomized;
>   fallbacks would be provided so that existing content would not break.
> Is that still true?

When that statement was made it was understood that Blink was replacing 
their C++ SMIL implementation with a JS one. From an authoring or spec 
point of view, such as change would be transparent.

Since then, Blink announced their intention to deprecate SMIL.[1] Based 
on that the SVG WG resolved to move those features to a separate module 
so that the discussion around SVG animation doesn't impact SVG2's 
schedule.[2]

> What I fear is a setback waiting until
>
> a)CSS is specced to bring into it functionality equivalent to that of
> SVG/SMIL
>
> b)browsers implement (at differential rates)  the new specs
>
> c)inconsistencies of implementations are experimented with and noted
>
> d)ambiguities of the spec are clarified
>
> e)browser bugs are reduced to the level we currently have for SVG/SMIL.
>
> That is the process that took place between SVG1.1 and the present –
> about 15 years.

It's certainly going to take a while to get these new features 
implemented and shipped to the point where they are commonly available. 
Hopefully not 15 years though.

> Brian, where is the best place for us to contribute to, to make sure
> that needs are properly assessed and that economic harm is minimized?

There are a few areas that come to mind:

1) Contribute to web-platform-tests.[3] Browser vendors are increasingly 
cooperating on this shared pool of tests and this is probably our best 
hope for achieving interop on new features.

2) Contribute to implementing these new features in browsers. That may 
sound daunting but if you can find a mentor they'll guide you through 
the long and tedious process and it's incredibly satisfying if you 
follow it through. You personally can ensure we get interop and can help 
shape the Web for millions of developers and billions of users. (I got 
involved in this discussion by implementing SVG animation in Firefox as 
a volunteer and found people incredibly supportive.)

3) Work on a fully spec-complaint JS implementation of SVG animation 
that could be shipped in browsers? Most SMIL polyfills are pretty 
limited in what they can do and don't handle the kind of edge cases that 
a native implementation needs to, nor have the required performance 
characteristics.

I'd like to rewrite the implementation in Firefox in JS on top of Web 
Animations (it would be faster and more secure that way) but it's a big 
project. If there were a good JS implementation available that browser 
vendors could collaborate on, it might be easier to convince them to 
ship it.

(On a technical note, I'm talking about a JS implementation intended for 
shipping inside browsers and hence may have special privileges so it 
can, for example, implement <animate> as a custom element.)

4) At some point the Animation Elements spec[4] needs to get written but 
I don't have bandwidth for it this year. If someone wants to help 
though, I can guide them along. Unfortunately, I think that someone 
needs to be a part of W3C member organization? Can anyone correct me on 
that?

They are just some ideas anyway.

Thanks for all your help already!

Best regards,

Brian

[1] 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/5o0yiO440LM
[2] http://www.w3.org/2015/04/30-svg-minutes.html#item02
[3] https://github.com/w3c/web-platform-tests/#contributing
[4] https://svgwg.org/specs/animation-elements/

Received on Thursday, 4 June 2015 02:13:21 UTC