Re: Animating SVG attributes from Web Animations


> On Jun 16, 2015, at 3:31 AM, Shane Stephens <shans@google.com> wrote:
> 
> Hi list,
> 
> One of the goals of Web Animations is to enable animation of any SVG attribute (whether presentation or otherwise). For many attributes this will simply involve a 50% flip, but there are attributes (e.g. 'd') that aren't presentation attributes but nevertheless have smooth interpolation behaviors.
> 
> Our hope was that these attributes could be referenced directly by name in a Web Animations keyframe list - for example:
> 
> svgElement.animate([{d: 'l 100 100'}, {d: 'l 200 200'}], 1000);
> 
> However, I've become worried that this might get in the way of future promotions of attributes to presentation attributes, particularly in cases where CSS provides or wants to provide similar functionality. Particularly, having Web Animations able to animate properties directly may end up prohibiting the creation of shadow CSS properties with non-compatible syntax but the same name.
> 
> For example, if Web Animations had predated the promotion of transform in SVG, and lots of content arose animating unit-less values, then there would have been more thorny issues to resolve when attempting to unify the CSS 'transform' property between HTML and SVG.
> 
> As a simple guard against this, I'd like to propose that we specify that references to svg attributes from Web Animations must be preceded by 'svg' and an initial capital letter - so instead of 'd', one must use 'svgD'. This matches what's already specified for references to 'offset' - Web Animations reserves this keyword for keyframe offsets, and to animate the SVG attribute one must use 'svgOffset'. So the example above would become:
> 
> svgElement.animate([{svgD: 'l 100 100'}, {svgD: 'l 200 200'}], 1000);
> 
> We hope that in the long term:
> * all SVG attributes that people want to animate are promoted to presentation attributes
> * all new Web Animations content animates properties rather than attributes.
> 
> Requiring that SVG attribute access be prefixed will help convince authors to move across to property access when available. Furthermore, once we get to this point (and if we don't run afoul of the issue that I'm worried about), then engines can choose to simply remove the 'svg' prefixes before processing keyframes.
> 
> Thoughts?

Shall WebAnimation also animate HTML attributes at some point? If yes, shall these attributes be “html” prefixed as well? What happens with the “svg*” attribute animation once we promoted the attribute to a CSS property/ presentation attribute?

Dirk

> 
> Cheers,
>     -Shane

Received on Tuesday, 16 June 2015 05:03:41 UTC