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

On Tue, 07 Oct 2008 14:24:05 +0200, Julien Reichel <Julien.Reichel@spinetix.com> wrote:

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

Your question boils down to: when is the 'begin' attribute evaluated? My guess is that neither SVG nor SMIL will give a satisfying answer at this time, but what I think should happen is that 'begin' should be evaluated in conjunction with starting the document timeline, which would be dependent on the 'timelineBegin' attribute.

Once the 'begin' time has been resolved I think it shouldn't change, so that if the 'anim' element had started and the 'id1' and 'id2' id:s were exchanged, the begin time would not be re-resolved. I think SMIL says that already.

It might be possible to see the above example as a case where the tree is being built, in which case it might be allowed to modify the animation elements. It's a maybe though.

> this script will have the same effect as this one (not allowed)
>
> <script>
> anim = document.getElementById("anim");
> anim.setTrait("begin', "id2.begin");
> </script>

Currently this would give you the well-defined behaviour of not modifying the 'begin' attribute, and to throw an exception.

If setTrait was changed to not throw in these cases, and the 'anim' element had a resolved begin time already, would you expect setTrait to affect the animation? How?

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

It's always good to illustrate the problem :)

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

Ok, would any of the following options satisfy you?

a) don't throw exception, do attribute modification, but disallow the modification from having an effect (similar to how setAttributeNS is defined to work)
b) don't throw exception, don't do attribite modification at all (silently ignore error)
c) don't throw exception, do attribute modification, allow modification to have an effect (and if so, what effect?)
d) something else (additional details you can provide here much appreciated)

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 Wednesday, 8 October 2008 14:31:50 UTC