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

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

From: Robin Berjon <robin@berjon.com>
Date: Thu, 30 Oct 2008 12:37:37 +0100
Cc: Erik Dahlström <ed@opera.com>, <www-svg@w3.org>
Message-Id: <AC87280B-2142-4DE2-86B3-57BE045528A1@berjon.com>
To: Julien Reichel <Julien.Reichel@spinetix.com>

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 11:38:13 UTC

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