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

Hi Robin and Julien.

Julien Reichel:
>> 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.

Robin Berjon:
> 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.

Yes. :/

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

In the future, I think the former is what we want.

Julien Reichel:
> 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 ?

It depends on the value of @timelineBegin on the rootmost <svg> element.
If "onLoad" (which is the lacuna value), then the timeline begins just
when the "load" event is dispatched to the rootmost <svg> element (which
is after <script>s get executed).  If "onStart", then the timeline
begins just after the opening tag of the rootmost <svg> element is
parsed.

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

Yes.  (Otherwise script-generated animation elements would not work.)

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

We decided to use the suggestion from your previous email of it being
not specified.

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

Yes.

So as a result of discussing this yesterday in the WG, the following
text has been added to the “16.2.4 Attributes to identify the target
element for an animation” section:

  If the 'xml:id' or 'id' attribute of an element that is the target of
  an animation is changed, then whether this affects the animation is
  undefined.  Future specifications will describe in more detail the
  result of modifying elements that affect animation elements that are
  already in the document tree.
  
  Resolution of the animation target occurs once the animation element
  is inserted into the document tree or at the document begin time,
  whichever is later.  (See also the 'timelineBegin' attribute, which
  controls when the document begin time occurs.)
   — http://dev.w3.org/SVG/profiles/1.2T/publish/animate.html#TargetElement

If you could indicate whether you are satisified with this resolution as
soon as possible, this would be appreciated.

Thanks,

Cameron
(ACTION-2344)

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 31 October 2008 01:20:51 UTC