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

On Mon, Oct 18, 2010 at 12:49 PM, Alex Danilo <alex@abbra.com> wrote:

> So, if at t=3.5s you serialize the output of (2) you should be able to read
> that serialization in and see what you were looking at in the browser.
>
> If the attribute is created in the DOM from the SMIL animation that has
> run, the serialized output of (2) will represent what you see on the
> screen. So
> you can reload the serialized tree and it will lok the same. You can even
> edit
> the animation node out in a text editor and see the visual result that you
> were
> trying to save.
>
> If the attribute is not created in the DOM, the serialized output of the
> tree will _not_ represent what you see on the screen. Less than optimal
> IMO.
>
> I would consider Opera's behaviour a feature rather than assuming it's
> a bug.
>

In fact, in the given example Opera inserts a "stroke-dasharray" attribute
with an empty value, so this serialization use-case would not work in Opera.

I don't think there's any real utility to authors for requiring an empty
attribute to be inserted into the DOM for animations to run, and I strongly
object to the browser automatically inserting one, on the grounds that the
DOM belongs to the author and browsers shouldn't modify it just to make
implementation easier. I hope Erik confirms this is just a small Opera bug
:-).

Serializing the current state of the animation would be an interesting
feature, but I think the default should be that content round-trips intact.
For example an editor for animated images would NOT want this when saving an
animated image.

>
Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]