Re: The intersection of scripting and the use element

Hi G. Wade,

--Original Message--:
><snip/>
>> 	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.
>
>Except that script in the referencing document cannot effect the target
>of the 'use' if it is in another file. And, as I've found in my
>experiments, script in the referenced document is not executed or
>available.

OK, now I understand your query a bit better. It relates to external
<use> which implies a referenced document which does not share the
same script execution context as the referencing document.

What you seem to be trying to do (correct me if I'm wrong) is manipulate
the DOM of the referenced document from the referencing document.
This has been implemented in some viewers (Opera) by use of
the 'contentDocument' property on the <use> element. I can't remember
the syntax off the top of my head right now, but if you do something like:

var use_element = document.getElementById('my_use');
var referenced_doc = use_element.contentDocument;
var node_in_referenced_doc = referenced_doc.getElementById('foo');

should look up 'foo' in the referenced document at least in Opera.

It's late so there may be errors above, but hopefully this helps.

Alex

>It may not have been clear from my original comment, but this query
>relates specifically to 'use' referencing elements from a separate
>document than the main SVG image.
>
>> 	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.
>
>I understand that. The 'use' element appeals to my sense of proper
>design. That is probably because I am definitely more of a programmer
>than a designer.
>
>Thanks for your input.
>G. Wade
>
>
>> --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
>> >
>> >
>> >
>> >
>> 
>
>
>-- 
>A 'language' is a dialect with an army.
>
>

Received on Monday, 8 November 2010 13:31:20 UTC