W3C home > Mailing lists > Public > www-svg@w3.org > October 2008

RE: [1.2T LC]: accessing rules for traitAccess

From: Julien Reichel <Julien.Reichel@spinetix.com>
Date: Thu, 30 Oct 2008 16:11:10 +0100
Message-ID: <364D31930BDB974AB40E22C5C2E584ED1E6FF6@asterix.SPINETIX.local>
To: "Robin Berjon" <robin@berjon.com>
Cc: Erik Dahlström <ed@opera.com>, <www-svg@w3.org>

Hi Robin,

I think there as been some follow up on this topic by andrew and me.

"  - everything (including hrefs) is resolved when the timeline begins,  
and thereafter you can change IDs, move elements around, etc. whatever  
was resolved stays resolved."

this looks like a good option to me. At least the behavior is specified. 
"timeline begins" means after the execution of the <script>'s right ? Is it also after (or before) the processing of the onload events ?

What about animation added to the rendering tree after the timeline as begun ? I suppose that in this case the href are resolved at the time of insertion. 

So the modification of the id (in regards to the SMIL animation) would be equivalent to the modification of the href using setAttribute. The modification of the tree has no influence on the SMIL animation itself. 

I also suppose that if you modify the id of an element and then add an animation using this id, the animation target should be the new element right ?


-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Robin Berjon
Sent: jeudi 30 octobre 2008 12:38
To: Julien Reichel
Cc: Erik Dahlström; www-svg@w3.org
Subject: Re: [1.2T LC]: accessing rules for traitAccess

On Oct 10, 2008, at 09:50 , Julien Reichel wrote:
> Thanks for your answers. I agree that my examples with the begin  
> raise the question "when is the begin evaluated". Actually this was  
> ways beyond the scope of my question, and honestly I don't know. And  
> I don't think there is a simple answer to that question. So the  
> simpliest would be to disallow such modification of the IDs.
> If I focus on the case of the href, (modifiying the href using  
> setTrait or modifying IDs of the element the href refere to, like  
> for my begin example), I understand that according to the current  
> spec the following happen:
> if I do
> <script>
> anim = document.getElementById("anim");
> anim.setTrait("href, "id2 ");
> </script>
> this throw an exception, but I I do
> <script>
> v1 = document.getElementById("id1");
> v2 = document.getElementById("id2");
> v1.id='id2';
> v2.id='id1';
> </script>
> This throw nothing, but also has no effect (Correct?)
> So my recommended option would be that:
> - The attribute xml:id cannot be modified once the element has been  
> inserted in the tree. (so modifying the xml:id of an element in the  
> tree should raise a NOT_SUPPORTED_ERR)
> This way the same behavior would be observed in both cases. Anyhow,  
> IMHO I don't see any legitimate reason for modifying IDs of element  
> already in the tree.

I don't think that this is the right solution to this issue. Indeed,  
one could remove both the elements that have those IDs, then introduce  
new elements with the same IDs, and you would have the same problem  
all over again. We can't just restrict editing the tree because of  
these SMIL reference issues. SMIL was defined without considering the  
cases in which the DOM would get modified, which really, really shows  
at times and is something of a pain.

So to make this simpler, I propose to use one of two options:

  - either it is possible to change the href of an animation so that  
it may apply to a new element; or
  - everything (including hrefs) is resolved when the timeline begins,  
and thereafter you can change IDs, move elements around, etc. whatever  
was resolved stays resolved.

I think the first one is more intuitive and more powerful, but it  
might cause issues in implementations (e.g. what happens if you change  
the href in the middle of the 27th repeat of an additive animation?).

Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/
Received on Thursday, 30 October 2008 15:12:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:20 UTC