Fw: The intersection of scripting and the use element

Drat. (I'm really having problems with "Reply All" today.)

Hi Alex,

On Tue, 09 Nov 2010 00:30:39 +1100
Alex Danilo <alex@abbra.com> wrote:

> Hi G. Wade,

(BTW, The "G." is normally silent. I sign things that way to
distinguish myself from another Wade Johnson in the general area.)

> --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.

Okay. That would seem to match what I'm seeing.

> 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.

I seem to have given the mistaken impression that I have a problem I'm
trying to solve. While that may come later, at the moment I'm probing
my understanding of the spec and I find that I (or the spec) am missing
something.

At the moment, my tests are much simpler. Let's say the referenced
element looks like:

<rect id="scriptedrect" x="10" y="10" width="100" height="100"
     onload="alert( 'Here I am!');" />

What should I expect to happen, when this is referenced from another
image?

How about this construction?

<rect id="scriptedrect" x="10" y="10" width="100" height="100"
     onclick="alert( 'Here I am!');" />

Another odd case,

<g id="scriptedrect">
   <script type="application/ecmascript">
       alert( 'script loaded' );
       function foo() {
	   alert( 'foo called' );
       }
   </script>
   <rect x="10" y="10" width="100" height="100"
        onclick="foo()" />
</g>

My problem is that I can't find any explanation in the spec that tells
me what I should expect from these examples. If the scripting is
effectively stripped on <use>, I'm fine with that. But, can I always
rely on that happening or is it just on artifact of current
implementations?

Thanks for helping me understand the current implementations better.
G. Wade

> >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.
> >
> >
> 
> 


-- 
There are only two kinds of programming languages: those people always
bitch about and those nobody uses.              -- Bjarne Stroustrup


-- 
Always hold a grudge. Keeps the memory sharp.  -- Hagar the Horrible

Received on Tuesday, 9 November 2010 04:27:51 UTC