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

Hi, Alex-

Alex Danilo wrote (on 10/17/10 9:35 PM):
>
>  You didn't read my previous response.

Sorry, I wrote my message beforehand, and just now sent it... I was 
messing around with this in several browsers:
   http://schepers.cc/svg/animation/attribute-value.svg

Seems WebKit doesn't implement the 'onend' attribute on SMIL elements, 
pity...

> --Original Message--:
>>
>>Bjoern Hoehrmann wrote (on 10/17/10 8:14 PM):
>>>  * Alex Danilo wrote:
>>>>Nothing in the spec. says animations shouldn't change the DOM either.
>>>
>>>  "When an animation is running, it should not actually change
>>>  the attribute values in the DOM." -- SMIL 2.1, section 3.3.1.
>>
>>Yes, it's more like a CSS presentation value than an attribute value.
>>
>>There have been times that I wished SMIL animation could change the DOM,
>>but the SMIL spec is clear, as Björn points out.
>
> Wrong. SMIL says attribute _value_. And this is a "should" guide and
> implementations do exactly what is said - maintain the base and
> animated values.

I agree with you that SMIL is rather poorly written.  It uses the 
RFC2119 conformance keywords far too loosely, and is too vague about the 
DOM, leaving us to guess about the intent.  However, on further 
examination, it does seem that that SMIL spec intended to allow 
implementations to vary a bit here [1]:

[[
When an animation is running, it does not actually change the attribute 
values in the DOM. The animation runtime should ideally maintain a 
presentation value for any target attribute, separate from the DOM, CSS, 
or other object model (OM) in which the target attribute is defined. The 
presentation value is reflected in the display form of the document. The 
effect of animations is to manipulate this presentation value, and not 
to affect the underlying DOM or CSS OM values.

...

In some implementations of DOM, it may be difficult or impractical to 
maintain a presentation value as described. CSS values should always be 
supported as described, as the CSS-OM provides a mechanism to do so. In 
implementations that do not support separate presentation values for 
general XML DOM properties, the implementation must at least restore the 
original value when animations no longer have an effect.
]]

So, it's clearly a SHOULD, though I think that's a poor decision for 
interoperability.  So, an implementation is allowed to change attribute 
values, and even to add attributes, it seems... but that seems like a 
nightmare for authors.


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

This is also a bit messy.  Since 'height' is a geometry attribute, and 
not a presentation attribute, and the CSS 'height' property doesn't 
affect SVG elements, it should be clear that this is the SMIL 
presentation OM, not either XML or CSS OMs.  It's working off the 
default or lacuna value here, which is '0'.  SMIL is clear that this is 
meant to be presentational only, not working on any DOM values, though 
again, it gives itself wiggle room here.


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

attributeType="XML" only has an effect when there is a conflict... it's 
not saying that it's meant to affect the XML attribute, it's saying that 
the presentation value it's starting with is the one from the XML DOM. 
In this case, since there is no 'height' attribute, that value 
"defaults" to '0'.  This is sorta stated in the SMIL spec [2] and Dick 
Bulterman has a more prosaic description in his book [3].


But regardless of what SMIL says on the matter, what we really want is 
interoperability, right?  We can always clarify in a spec what behavior 
we all agree to, if we can all agree... this would be best for authors.

So, logically speaking, which behavior do we want, knowing what we all 
know now from implementing it and authoring to it?


[1] 
http://www.w3.org/TR/SMIL/smil-animation.html#animationNS-AnimationSandwichModel
[2] http://www.w3.org/TR/SMIL/smil-animation.html#adef-attributeType
[3] 
http://books.google.com/books?id=XTyWkvpLZVwC&pg=PA371&lpg=PA371&dq=smil+attributeType&source=bl&ots=c0h4yz4P2k&sig=3-huzBcV9v_n45itZYF18_nBuIo&hl=en&ei=dqm7TMTBLsOclgfTg6DMDQ&sa=X&oi=book_result&ct=result&resnum=4&ved=0CCEQ6AEwAw#v=onepage&q=smil%20attributeType&f=false

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Monday, 18 October 2010 02:31:41 UTC