Re: Animating SVG attributes from Web Animations

On Wed, Jun 17, 2015 at 6:53 AM Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

> 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.
>
> To be clear, Web Animations already allows this. I'm proposing a minor
restriction, so that svg attributes are less likely to interfere with
properties from presentation attributes in the future.


>
>    - 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.
>
> We should consider that. However, it's currently an SVG-specific problem
in that HTML doesn't have a large set of non-presentation properties that
are intended to be promoted soon. So any svg-prefixed attributes are soon
going to be legacy, while any html-prefixed attributes (if we ever define
any) are not. I don't know that it makes sense to use a consistent name
across the two cases.


>
>    - 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.)
>
> That's interesting. We'll work through the implications of automatic
promotion in a Web Animations meeting to see if we think there are going to
be problems.

>
>    - 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.
>
>
I think these problems are orthogonal to the original question:

Should animation of SVG attributes within a Web Animations animation
require use of the 'svg' prefix to specify the attribute, or not?

Either way, the same cascade questions apply. Dirk's suggestion of
restricting an animation to one or the other doesn't make any problems go
away - it just makes the Web Animations API less expressive. Having said
that, it'll still achieve my original goal of allowing promotion to happen
unimpeded so I won't be too upset if we end up taking that approach.

My current inclination is:
(1) adopt the 'svg' prefix (or if there are reasons that it won't work,
fall back to Dirk's suggestion).
(2) maintain the cascade - it's not perfect, but it works and it's baked in
at this point. This means that, yes, if you have an attribute animation and
you specify a CSS property then the property will win.
(3) gently nudge everyone towards a future world in which everything gets
resolved at the CSS level. This should mitigate (2) in the long run.

Cheers,
    -Shane

>
>    -
>
> ~ABR
>