- From: G. Wade Johnson <gwadej@anomaly.org>
- Date: Mon, 8 Nov 2010 22:27:15 -0600
- To: www-svg@w3.org
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