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

Hi Cam,

--Original Message--:
>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).

Sure, and  that supports my point. That statement in SMIL has nothing
to do with creation of attributes or modification of the DOM. It's about
having SMIL take the base value out of the DOM and generate
a modified presentation value from the base value (in some not
all cases).

>> > 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"/>
>  </rect>
>
>and expected them to (and found them to) animate.

I disagree.

There is no attribute 'height', and hence nothing to animate.
Since you 'expect' it to animate, then your expectation is
what people are assuming, and that assumption implies
synthesizing an attribute to be the target of the animation.
If the DOM can't be manipulated that way, then the animation
should not run IMO.

>> 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

True.

>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
>animVal.

Then what does it animate?

Does it maintain a separate in memory model to take the place of the
attribute during animation? The SMIL node does need to hold the result
of the animation, but surely that should be applied to the node that
is the target of the animation, and therefore its attribute. When you
say 'attributeName', are you really trying to say 'presentationValueName'?
The 'attribute' in 'attributeName' seems to imply attribute does it not?

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

A reasonable interpretation is consistency.

The attribute is there or not. The animation will run or not. If the animation
runs, the implementation must have created an attribute to be the target
of the 'attributeName'.

>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
>an SVG_LENGTHTYPE_UNKNOWN value.

I don't think the animation should happen. There is no attribute to
animate - Batik has a bug;-)

If you were to implement this behaviour for non-existent attributes
it would be more reasonable to throw an exception since the thing
doesn't exist as you said.

Brian pointed at the SMIL 3.0 rec which points out the the animation
_value_ comment is normative, which is fine as it relates to the
values not the existence of the attribute.

The same reference he points out (SMIL 3.0) in the same section
contains this: 
"Animations may be defined to either override or add to the base value of an attribute."

If there is no attribute, there is nothing to override or add to. No animation, sorry.

Alex

>-- 
>Cameron McCormack ≝ http://mcc.id.au/
>
>
>

Received on Monday, 18 October 2010 02:15:10 UTC