Re: <animateColor>

On Tuesday, October 12, 2010, 2:26:51 PM, ddailey wrote:

d> What does <animateColor> give us that <animate> doesn't? 

At this point, it gives nothing besides compatibility with content that uses it.

Originally, SVG just had animateColor (from SMIL) and animate (from SMIL, which could animate unitless scalar values, or space separated lists of unitless scalar values.

The smil folks were mainly looking at the lexical representation, so even #3F7 seemed like a non scalar value and certainly mediumPapayaWhip looked nothing like a scalar.

SVG, partly as a result of comments, extended animate to allow animation of attributes and properties which are, in fact once you understand them, lists of scalars. In other words, a benefit of integrating SMIL deeper into the host language of SVG was that it 'knew about' some attributes.

So #56F7C9 and rgb(12, 57, 98) and mediumPapayaWhip and currentColor and inherit are different lexical forms which at the end of the day evaluate to a triple of red, green and blue unitless scalar values, which SMIL-in-SVG can then happily animate.

That was rather later in the development of SVG though, and by then we already had animateColor so it was not removed.
 
d> I can't tell if the spec requires it, 

It does, although this was a later development in SVG and we kept around animateColor as well. Its also clearer in 1.1 than 1.0, clearer in 1.2T than 1.1, and clearer again in 1.1SE.

d> but all browsers seem to allow <animate 
d> attributeName="fill" values="purple;plum;papayawhip"  ...etc...> just fine.
d> Is it just out of the kind hearts of the browsers that this works or does
d> the spec require it?

The latter, plus the desire to not needlessly break content that uses it.
 


-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Received on Tuesday, 12 October 2010 21:28:52 UTC