> On Jun 16, 2015, at 3:31 AM, Shane Stephens <[email protected]> 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
