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

(I don’t want to spend too much time on this, but:)

Cameron McCormack:
> >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.

Alex Danilo:
> Then what does it animate?

What it “animates” is the rectangle on the screen.  What it affects, in
SVG, is SVGAnimatedLength.animVal.  SVGAnimatedLength.animVal is the
value that is used for rendering.  An SVGAnimatedLength exists
regardless of whether there is a height="" attribute on the element.

> Does it maintain a separate in memory model to take the place of the
> attribute during animation?

To take the place of the height="" attribute?  No.  While the height=""
attribute and its corresponding SVGAnimatedLength object are coupled,
they are still separate entities.  The SVGAnimatedLength.animVal is
where the animated length value is stored.

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

Yes,

> and therefore its attribute.

but no, I don’t think that follows necessarily.  It can be applied to
the SVGAnimatedLength.

In my mental model, XML attributes are just a way to give values via
strings to SVGAnimatedBlah objects (for those attributes that such
objects exist).

> When you say 'attributeName', are you really trying to say
> 'presentationValueName'?  The 'attribute' in 'attributeName' seems to
> imply attribute does it not?

Not when attributeType="CSS". :-)  The word “attribute” here must somehow
refer both to DOM Attr nodes and CSS properties.  So I take “attribute”
in the word “attributeName” to be something more abstract.

And I do think that the animation is targetting something like the
“trait” of the element.  attributeType="XML" doesn’t mean it’s modifying
the XML attribute itself; it’s modifying whatever abstract thing that
XML attribute represents.

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

Another way of looking at consistency:

  * a CSS property need not be specified on that element for a CSS
    animation to succeed (or do you argue that this shouldn’t work
    either?)

  * the lack of an x="" attribute on a <rect> just means the x
    coordinate is 0; it doesn’t impede processing otherwise.  Why should
    animations stop working here?

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

I don’t think throwing an exception from a declarative SMIL animation
element is appropriate.

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

Sure.

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

So maybe our disagreement comes down to what “attribute” means in this
context. ;)


Regardless, this shouldn’t be tightened up in spec text.  We should
consider what behaviour is most useful for authors.  I contend (not
suprisingly? :)) that my interpretation is more useful.

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

Received on Monday, 18 October 2010 02:48:01 UTC