- From: Alex Danilo <alex@abbra.com>
- Date: Mon, 08 Nov 2010 16:18:00 +1100
- To: "G. Wade Johnson" <gwadej@anomaly.org>
- Cc: www-svg@w3.org
Hi G. Wade, Boris explained well what the effect of the behaviour is. English being what it is makes things confusing. <use> doesn't have to clone, it's 'effect' is that of a clone. An implementation can do what it likes to achieve the desired behaviour. The spec. should probably have been written along the lines of "A <use> element enables the SVG DOM tree to be treated as a directed acyclic graph (DAG). The effect of the <use> element instance is as if a clone of the target of the <use> had been made" or something like that. If a script changes a DOM node in the target of the <use> and there are 100 references to that same target, all the references will change. It's a live clone in effect. Modern rendering architectures such as in the Shake application started to use DAGs years ago instead of simple n-ary tress. <use> is the way SVG provides similar functionality. Alex --Original Message--: >A co-worker of mine has been experimenting with the SVG use element >now that it is implemented more widely and reliably in browsers. >The problem he brought up has to do with script elements. Should >script elements from a <use>d element/image be accessible from the >main SVG? > >Just as usefully, should we be able to combine some graphical elements >and script into an SVG that gets used into another SVG as a functional >component? > >Current testing appears to say 'no'. I've tried various combinations >of scripting in the referenced element without anything working. As a >final test, I tried the same thing with referencing an element >containing SMIL animation and that works (at least in Opera). > >I began digging around in the SVG 1.1 specifications to see if I could >clear this up definitively. > >In section 5.6 of the SVG 1.1 document, I find the following: > >1. "The Ħuse˘ element references another element and indicates that the > graphical contents of that element is included/drawn at that given > point in the document." > >This would imply that only graphical elements can be included by a use >reference. Does that mean that animation should not be included? This >is later clarified by the statement: > >2. "Animations on a referenced element will cause the instances to also > be animated." > >Which explicitly allows animations to be referenced as part of the >referenced element. > >3. "The effect of a Ħuse˘ element is as if the contents of the > referenced element were deeply cloned into a separate non-exposed DOM > tree which had the Ħuse˘ element as its parent and all of the Ħuse˘ > element's ancestors as its higher-level ancestors." > >This statement does not make any distinctions about the kinds of >elements copied. It is conceivable "the contents of the referenced >element" would apply to script elements included within a referenced >'g' element. > >4. "The event handling for the non-exposed tree works as if the > referenced element had been textually included as a deeply cloned > child of the Ħuse˘ element, except that events are dispatched to the > SVGElementInstance objects." > >Now this could imply that at least event handling attributes are >have the appropriate scripting copied from the reference. However, >experimentation suggests that the copied hander references scripting >from the referencing document, not the referenced document. This seems >somewhat counter-intuitive. > >This is also the second reference to concept that some functionality >should act as if the referenced element were "textually included" at >the point of the 'use'. Since the document earlier states that > >5. "... the referenced element were deeply cloned into a separate > non-exposed DOM tree ..." > >we can be sure that the spec does not require actual textual inclusion. >But, this does not explain the expectations for included script >elements. > >Finally, the section that begins > >6. "A Ħuse˘ element has the same visual effect as if the Ħuse˘ element > were replaced by the following generated content:" > >lists a series of conceptual transformations that would be used to >convert different forms of referenced content into an equivalent model >in the referencing document. Nowhere in that explanation is there any >mention of what should happen if scripting were part of the referenced >element. > >Based on the implementations, it looks like scripting inside the >referenced element is just discarded. Unfortunately, the specification >does not actually state what should happen. > >Does anyone know what the intent of the 'use' element with respect to >referenced scripting is? Whichever way this should be interpreted, the >specification should probably be more clear on this point. > >Thank you for taking the time to read this little rant. >G. Wade Johnson > > > >
Received on Monday, 8 November 2010 05:18:40 UTC