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

Okay, I think I follow enough of this discussion to arrive at the following 
conclusions:

1. I'll hold off for now on filing a bug report with Opera.
2. I may wait a few days to ask my next couple of questions.

;)

More seriously, I  knew barely enough to suspect the question might be 
tricky.

If it helps to know, UA consistency here was not crucial to any profound 
authorial intent in this case -- I was developing some course material this 
weekend that involved comparisons of SMIL and script and just happened to 
get curious about the question. I was actually expecting it to be the way 
Opera handled it, but that expectation made me a bit nervous since once I 
"added" the attribute stroke-dasharray to the object through SMIL I could 
see no way to remove it through SMIL. <set attributeName="stroke-dasharray" 
begin="mouseout" to="null">, which would have paralleled my script approach, 
didn't seem to work (nor did to=""), and to="0" was the only thing that 
seemed to remove the property's appearance once it had been defined.

cheers
David
----- Original Message ----- 
From: "Erik Dahlstrom" <ed@opera.com>
To: "Alex Danilo" <alex@abbra.com>; "Robert O'Callahan" 
<robert@ocallahan.org>
Cc: "ddailey" <ddailey@zoominternet.net>; <www-svg@w3.org>
Sent: Monday, October 18, 2010 4:24 AM
Subject: 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 11:49:33 UTC