Re: The intersection of scripting and the use element

Hi Alex,

On Mon, 08 Nov 2010 16:18:00 +1100
Alex Danilo <alex@abbra.com> wrote:

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

I actually feel that the spec does a good job of clearly specifying
what happens with the "graphical" elements. In addition, the explicit
statement about animation elements that are included by the referenced
element handles that case.

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

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:14:25 UTC