- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 31 Oct 2008 12:20:00 +1100
- To: www-svg@w3.org
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