Animating SVG attributes from Web Animations

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?

Cheers,
    -Shane