W3C home > Mailing lists > Public > www-svg@w3.org > February 2000

Re: Embedding and scripting within SVG

From: Jon Ferraiolo <jferraio@Adobe.COM>
Date: Thu, 03 Feb 2000 09:09:11 -0800
Message-Id: <200002031705.JAA16707@mail-345.corp.Adobe.COM>
To: Colm Smyth - Sun Ireland <Colm.Smyth@ireland.sun.com>
Cc: www-svg@w3.org
Colm,

At 12:07 PM 2/3/00 +0100, Colm Smyth - Sun Ireland wrote:
>Hi SVG-ites,
>
>Reading the SVG specification and a quick search on the public SVG 
>mailing list suggests that there is a strong interest in embedding
>SVG in HTML or other host languages. The discussion on embedding
>foreign object types in the 6th July '99 working draft suggests that
>the embedded object is likely to be a renderable XML fragment.
>
>Clearly SVG is targetted primarily as 2d graphics description language,
>but browsers are likely to be the most frequent rendering environment.
>In a browser, interactivity is key.
>
>Briefly, I see benefits in being able to embed Java applets and assign
>JavaScript code fragments to events similar to HTML. These embedded
>objects are relatively 'opaque' to XML parsers.

I'm not sure if I exactly understand what you are requesting, but I'll do
my best to respond.

The SVG specification requires JavaScript (i.e., formally, ECMAScript)
support in "Conforming Dynamic SVG Viewers". (See the Conformance Criteria
appendix. In the Dec3 draft, that appendix is informative, but in newer
drafts it will be normative.) Thus, conforming implementations in
interactive environments are required to support an ECMAScript binding of
the DOM.

We don't say that a Java binding of the DOM is required. Thus, Java hookups
to SVG are an optional extension that certain implementations can choose to
provide.

>
>The up-side is interactivity and re-use of existing code components. 
>
>The down-side is that few pure SVG renderers could do anything meaningful
>with an embedded applet. Event-handlers are not a problem as they can
>be simply ignored by a renderer that doesn't support interaction so 
>this falls cleanly within the scope of SVG's goals.
>
>It would be possible to offset the inability to render the graphical
>representation of, say, a running Java applet by providing a static
>image (JPG, PNG) as a fallback rendering. This would require some
>additional syntax in SVG as the image-rendering should be done by
>the SVG engine.

SVG does have an <image> element and a <switch> element with a
'system-required' attribute than can be used to display a fallback image in
case a given implementation does not support "SVGDynamic" or "SVGDOM".

(Look at
http://www.w3.org/TR/1999/WD-SVG-19991203/struct.html#ConditionalProcessing
and http://www.w3.org/TR/1999/WD-SVG-19991203/struct.html#ImageElement)

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated


>
>I'm not a member of this alias, but I would welcome feedback on these
>proposals; please cc me on responses.
>
>Thanks for your time!
>
>Colm Smyth
>WT SE Sun Microsystems Ireland
> 
Received on Thursday, 3 February 2000 12:06:21 GMT

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