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

Hi Cam,

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

Nor do I, see how such a simple question can lead to so much
discussion and identification of edge cases that no-one has
considered. So much so that at least one mainstream browser
product implements it completely differently to others.

Interoperability is the most important thing here I think we
all agree.

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

I think you forgot about Tiny 1.1 which has no script, no DOM yet the
same SMIL language hosted in it. There is no such thing as an
'SVGAnimatedLength' in there. One could choose to model it
similarly but it is not required. There isn't any CSS there either
and so, the only thing that can be animated is an attribute.

There is no 'height' in the DOM. The base value in the XML DOM
gets looked at, it's a required attribute so the element should not render.

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

I agree you can calculate a value in some cases, but not all without
specifying what happens - i.e. create a new attribute or use the
lacuna value as you suggested.

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

I guess that's a reasonable interpretation.

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

No, because there is a user agent style sheet and there are known
defaults for presentation properties, whilst the attribute is a component
of the thing that was parsed into an XML DOM. They are different.

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

>From SVG: "If the attribute is not specified, the effect is as if a value of "0" were specified."
So we have a clear indication from the host language that the effect is
that of an attribute being there, and that is like the 'implicilty targeted'
attribute in SMIL. SVG sets specific rules for 'x' and 'y' in those
cases, just like we need to set specific rules if you try to animate
something that's not there.

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

I meant when you try to fetch the base value on a non-existent
attribute from script, not from the SMIL machinery.

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

I don't think it's disagreement. It's discussion about what is correct
and what authors would like to happen. In Opera's case, they've
made the call that authors would like it to run and so do you. In
their case, they've done the old HTML thing and taken the approach
of adding the attribute for them, just like HTML would kind of add
end tags, reorder tags like <i><b></i></b> and that sort of thing
and it's a reasonable thing to do when the spec. doesn't tell
you what to do.

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

It should be tightened up in spec text. That's what the spec. is for.

I agree your interpreation is what authors would expect and what
I would expect to happen too.

But in order for the animation to run, SVG needs to define if adding
a new attribute is kosher, or whether we define use of tha lacuna
value in the absence of an XML DOM representation. Or less
usefully, disallow the animation from running.

>From an implementation POV, adding an attribute is the easiest
thing to do, and will require a lot less code to implement than
special casing the exists/doesn't exist case. That probably
matters in low memory environments, but on a desktop or
Java environment, you're already assuming lots of memory
to burn so not as important.

SMIL lives on top of the DOM, and SVG lives on top of SMIL
so I guess we need to decide what to do. Consistency for all
implementations should be the goal. The implementers will
build whatever is specified regardless of the pain, but it does
need to be specified since we already see divergent implementations.

Maybe when the Europeans wake up, Erik will pitch in a few
comments (most likely in amazement of the sheer amount of
email an itty bitty little question tiggered). Sorry Erik:-)

Alex

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

Received on Monday, 18 October 2010 03:24:17 UTC