Re: Animating SVG attributes from Web Animations

Some thoughts on the proposals & points raised by both Shane and Dirk:

   - Most existing animation libraries have two parallel methods, one for
   style properties and one for attributes.  There are practical reasons this
   is so (because those library methods are accessing different DOM methods),
   but it is an API users will be familiar with.  I like the idea of being
   able to animate styles and attributes with the same animation object, but I
   don't think it is an absolute requirement.

   - I would prefer a syntax that emphasized the "attribute" nature of the
   property being animated, rather than the "svg" nature.  Otherwise, you're
   going to have users trying to animate "svgFill" and other svg-specific
   style properties.  Also, as Dirk said, SVG is not the only situation where
   you might want to animate attributes (e.g., there are numeric attributes on
   HTML <input> elements).  And there are efforts to harmonize many SVG/HTML
   attribute names.

   - Although the SVG WG agreed to neuter `attributeType` for SMIL
   animations (so that the animation always applies to a style property if one
   exists by that name), we really did not think through the complications
   that arise when the style and attribute have different syntax or
   applications (e.g., transform or  font-size without units, or when an
   attribute has an effect on a given element but a style property isn't, but
   that style property exists for other elements (various elements are
   currently excluded from the new SVG layout properties, such as text and
   gradients).

   Until we clean up all those complications, I'm not sure about adopting
   the same approach for automatic-resolution of property names in Web
   Animations.  (And the SVG WG has put work on animations aside for now, so
   we will likely synchronize with Web Animations rather than expecting you to
   do the reverse.)

   - In contrast, the main issue with allowing the author to specify style
   versus attribute, as Dirk mentions, is the CSS cascade.  If you animate a
   presentation attribute that is over-ridden by a style rule, it would not
   have an effect.  So the browser needs to check where the current computed
   style comes from before modifying it.

   I can imagine cases where the over-ride could be useful (e.g., over-ride
   a continuous animation with a :hover effect), although for those few cases
   you can use !important.  On the other hand, the fact that you have to deal
   with !important declarations already means that there must be a check (for
   whether the current rule is !important or not) before applying the
   animation.

   More generally, as browser support improves for the attr() function in
   CSS, there will need to be ways to keep track of which computed style rules
   depend on attributes, and update the computed value if the attribute is
   animated.  So finding a generalizable solution now might have dividends
   later.  After all, most presentation attribute functionality can be mapped
   to a browser stylesheet of the form `width: attr(width)`.  If that remains
   the cascaded value on an element, then animating the attribute will have an
   effect on the computed style.  If that rule is replaced within the cascade,
   then it doesn't.


~ABR