Re: [1.2T LC]: accessing rules for traitAccess (ISSUE-2094)

Hi, Julien-

Just to let you know, I've put this in our issue tracker as ISSUE-2094.

Thanks-
-Doug

Julien Reichel wrote (on 10/7/08 8:24 AM):
> Hi,
> 
> 
>>> Thus it is possible to modify the target of an animation by switching
>>> the xml:id of two elements (which is equivalent to a change of the href
>>> in the animation). So IMO this restriction  is insufficient to enable
>>> simplification of the UA design.  Note that modifying the xml:id of
>>> other even in the tree can also be used to modify the behavior of other
>>> attribute (like a begin="id1.begin" for instance)
> 
>>Well, the begin time would be resolved previously right?
> 
>>If the id 'id1' was missing at first, the begin time would be resolved as 
>> 'indefinite' (according to SMIL animation), and when the 'id1' was added 
>> to the document that still wouldn't cause a re-evaluation of the begin 
>> time (or at least I didn't find a reference that said one must do that 
>> in such a scenario).
> 
> I was thinking about an example more like this one:
> <svg>
> <video xml:id='id1' begin='10' ...>
> <video xml:id='id2' begin='5' ...>
> <g>
> <animate xml:id='anim' begin='id1.begin' ... >
> </g>
> <script>
> v1 = document.getElementById("id1");
> v2 = document.getElementById("id2");
> v1.id='id2';
> v2.id='id1';
> </script>
> 
> this script will have the same effect as this one (not allowed)
> 
> <script>
> anim = document.getElementById("anim");
> anim.setTrait("begin', "id2.begin");
> </script>
> 
> I don't know if that causes a problem, but IMO changing the ID let you modify pretty anything when using SMIL. (note that my example might be too simple, and full of errors to trigger the problems I was pointing out, but should explain the principle... hopefully)
> 
> My main point was:
> - there are some restriction concerning setTrait and SMIL, which will complicate the design of the script to handle those element, however those restriction are not sufficient for the implementer of UA to really be able to take advantage of them (IMHO). So removing those newly added restriction (they were not present in the previous version), actually simplify the content creation without additional implementation burden on the UA architects.
> 
> Julien
> 
>

Received on Tuesday, 7 October 2008 13:49:15 UTC