Using CSS Transitions/Animations with SVG attributes

[This discharges my action to summarize today's FXTF telcon discussion
about using CSS Transitions and Animations on SVG.]

At the 15Mar2011 FXTF conference call, we discussed the proposals for
applying CSS Transitions and Animations to SVG.

The essential problem is that only a handful of SVG attributes are
exposed as CSS properties that can theoretically be animated, such as
'fill'.  We'd like many more (possibly all) SVG attributes to be
exposed as properties that can then be animated with CSS.

The full proposals can be found at
<http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation>.
 I'll quickly summarize them here.

#1 proposes just directly promoting SVG attributes to CSS properties.
It has been generally rejected by the SVGWG.  It has several bad
properties, such as several properties with different syntaxes based
on the element it comes from, and the possibility of future global
conflict.

#2 proposes mapping some (possibly large) subset of SVG attributes
into properties with new names.  In this proposal, the affected
attributes would then become presentational attributes, acting the
same way that the existing presentational attributes in SVG and HTML
do.  The downside of this is that it would introduce many new CSS
properties.  The exact number that we can get away with is being
debated, but the smallest set so far is around 20.

#3 proposes introducing a new syntax for indicating that you want to
animate an SVG attribute's value.  You would use "attr(name)" on the
LHS of a rule, with the value on the RHS.  As this breaks CSS's Core
Grammar, this wouldn't be valid in normal declaration blocks, only in
@keyframes blocks.  This has the downside that it's impossible to use
CSS Transitions on the attributes.

Another proposal that vaguely resembles all of them is to introduce
all SVG attributes as attr-* or svg-* properties.  This would
introduce a large number of new properties and would make some
properties have different meanings/syntax on different elements, but
it's usable in both Transitions and Animations, and has no chance of
colliding with existing properties.



Personal opinions here now.  I strongly object to #3.  Anything which
can't be used in Transitions is a complete non-starter in my opinion.
I also strongly object to #1 and the fourth proposal, because having
properties that act significantly different on different elements is a
bad thing.  This leaves me with only #2 being acceptable.  I've been
working on the list of attributes we'd have to map over at
<http://www.xanthir.com/etc/animatable-svg-attributes.html> - several
map directly into existing properties and some may be collapsible into
single properties, so the actual list is roughly around 20.

~TJ

Received on Tuesday, 15 March 2011 22:24:20 UTC