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

On Mon, 18 Oct 2010 06:04:08 +0200, Robert O'Callahan  
<robert@ocallahan.org> wrote:

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

Ok, reading the whole thread (and yes Alex it does amaze me how much mail  
this issue generated ;) I see at least two separate points:

1. Animation of attributes that had no explicit basevalue in the markup
2. Animating a css property that had no specified presentation attribute  
results in an empty attribute being created/exposed in Opera

Let me throw in my 2c on each of these:

1. IMHO it's reasonable to automatically create base values when the  
corresponding attribute wasn't specified in the markup, so that animations  
run.
    Rationale: Simpler to author (less to write == less to transfer)
    Whether the created baseVal should be exposed to the DOM, that's a  
separate question, but it's possible it shouldn't be, see 2. I think it's  
not entirely unreasonable to do so, except in the case where there's  
really no baseVal (read: in the cases where the cascade contains the  
baseVal).
2. It's a side-effect of the implementation in Opera. You can animate both  
css properties and attributes (both presentation attributes and normal  
ones). The effect you see is because of how we store the data at the  
moment, it's all hanging off the attributes because we need to expose it  
to the DOM via animVal. There's no special filtering of attributes for  
this case at the moment. Now we could write an explicit baseVal to the DOM  
such that the attribute serialization saw something else than an empty  
string, but I'm not sure that's much better since it would have to be  
specialcased and synchronized with the cascade (PITA). Or we could hide  
the attribute for these cases. I think the latter makes the most sense.

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

Well, animating does mean that the DOM changes (the animVal). Changing the  
core DOM (the baseVal) is unintentional from our side, at least for the  
serialization.

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

I agree that that's not what you'd want. Empty attributes are rarely  
useful.

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Monday, 18 October 2010 08:25:05 UTC