Re: does <set> add an attribute to node.attributes

Doug Schepers:
> > There have been times that I wished SMIL animation could change the
> > DOM, but the SMIL spec is clear, as Björn points out.

Alex Danilo:
> Wrong. SMIL says attribute _value_. And this is a "should" guide and
> implementations do exactly what is said - maintain the base and
> animated values.

To be honest, I interpret that statement in the SMIL spec as saying that
animations are a layer on top of the DOM, and do not affect the DOM at
all (the values of or the creation of attributes).

> > I would say this is a bug in Opera, if it really does add an
> > attribute; that said, I suspect it won't make much difference for
> > most purposes.
> I would say that the animation should not happen if that is the case.
> If SMIL cannot change the DOM, there is no attribute to animate.

I disagree.  I have written things like

  <rect width="100">
    <animate attributeName="height" to="100" dur="1s"/>

and expected them to (and found them to) animate.

> If the animation says attributeType="XML" etc., or similar then it's
> not there and won't animate. Poor content authors.

I think attributeType="XML" exists only to disambiguate whether you are
targetting an attribute or a property animation.  That the attribute
doesn’t exist shouldn’t prevent the animation from working.  You can
have the SVGAnimatedLength object exist in the DOM without the actual
Attr node being there.  Batik doesn’t create an attribute if it doesn’t
exist, and it performs the animation and affects the SVGAnimatedLength

I’m not saying that all of this is explicitly supported by the specs,
but I think it is a reasonable interpretation.

A related to issue to the above is what the SVGAnimatedLength.baseVal
exposes for an attribute that doesn’t exist in the DOM.  That’s not
currently specified, and I think you could argue either that it should
reflect the default/lacuna value for that attribute or that it should be

Cameron McCormack ≝

Received on Monday, 18 October 2010 01:50:57 UTC