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


Hi David,

--Roc writes:
>On Mon, Oct 18, 2010 at 6:11 AM, ddailey <ddailey@zoominternet.net> wrote:
>
>In this funny little example:
>http://srufaculty.sru.edu/david.dailey/svg/test/changeAttr4a.svg
> 
>I measure the number of attributes associated with a node before and after applying a 
><set attributeName="stroke-dasharray" begin="mouseout" to="0" onbegin="aftercount()"/>
> 
>to an object that previously had no stroke-dasharray. 
> 
>Opera says the thing has 10 attributes before and 11 after. Firefox and ASV+IE tell me that it has 10 both before and after. Chrome and Safari seem a bit displeased with the experiment in general (handling the rollover effect in a way that makes me displeased and not enjoying my attempt to trigger script from set.begin  -- frankly I wasn't at all sure that that would work at all anyhow and was rather pleased to see that it did, so it may not be webkit's problem!)
>
>
>I think your example clearly should work, per spec. You should probably file a bug.
>
>
> Anyhow, I went looking in the SVG 1.1 spec to see if I could see relevant language, but didn't see the answer in any obvious place.
>
>
>Nothing in the spec says that animations should change the DOM, therefore they shouldn't change the DOM. I think Opera has a bug.

Nothing in the spec. says animations shouldn't change the DOM either.

Before assumptions are made, perhaps a little thought experiment is in order.

1) Start with something simple: a <rect>:

    <rect x="0" y="0" width="100" height="0">
        <animate id="foo" attributeName="height" begin="1s" dur="2s" from="0" to="100" fill="freeze"/>
    </rect>

2) The same thing but missing the height attribute:

    <rect x="0" y="0" width="100">
        <animate id="foo" attributeName="height" begin="1s" dur="2s" from="0" to="100" fill="freeze"/>
    </rect>

When height == 0, nothing is drawn in both cases. Between 1s and 3s both should show a rectangle
that grows from 0 to 100 in height.

What happens at t=3.1s say?

Does the rectangle in case (2) disappear again? No, because fill="freeze" and so the rect should
remain visible.

3) At t = 4s seconds we fire a script that does something like:

var fooel = document.getElementById("foo");
fooel.parentNode.removeChild(fooel);

What happens?

Does the rectangle remain visible in (1) but not iin (2)?

It would very likely confuse authors why removal of the animation node suddenly
made the rect disappear in (2). After all the attribute was animated and frozen at
t=3s. Removing the animation node which is _not doing anything_ and so not
taking part in an SMIL activity probably shouldn't affect the visual result.

Secondly, there is the issue of DOM serialization. From what I recall there
is no serialization of time.

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 the absence of clear direction in the recommendations, one should
never assume something is a bug when in fact intelligent people probably
thought through the implications of different architectures for implementation
and chose the one that is most consistent with the in-memory model
that they are intending to represent for maximal flexiblity and consistency.

Alex

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

Received on Sunday, 17 October 2010 23:50:21 UTC