W3C home > Mailing lists > Public > www-svg@w3.org > November 2010

The intersection of scripting and the use element

From: G. Wade Johnson <gwadej@anomaly.org>
Date: Sun, 7 Nov 2010 21:52:32 -0600
To: www-svg@w3.org
Message-ID: <20101107215232.720af8c2@sovvan>
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 03:53:09 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:46 GMT