Re: The intersection of scripting and the use element

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