Re: SVG 1.2 - SVGWindow

"Niklas Gustavsson" <niklas@protocol7.com> wrote in message
news:ascvc9$k27$1@main.gmane.org...

> * If possible (I don't know if this is within the powers of W3C) I think
> this sentence: "Interface SVGWindow provides a global object for scripts
> embedded in a SVG document." should be extended to say that the global
> object should be named "window"

A thing such as the global object isn't available in all languages, whilst
we're only really using javascript in client-side svg the WG can't be
javascript specific in case things change in the future.  I don't think
the WG should talk about global objects at all.  I'd also suggest the
SVGWindow Interface shouldn't be talked of as being global, as you note
it's confusing when embedded in other documents (or how about when the svg
document is a background image defined in CSS from another doc...)

> * Why are not DOM 3 Load and Save (http://www.w3.org/TR/DOM-Level-3-LS/)
> used? I think it makes a lot of sense to have one way of doing these
things
> within all W3C technologies, even though the current SVG viewers has
> getURL/postURL/printNode/parseNode. Viewers will have to be updated to
> support SVG 1.2 anyways and authors that today use the extensions should
be
> aware that this is not according to any spec.

DOM3 L&S doesn't do the same job, for example they don't provide a getURL
or postURL - all they all provide is a load XML from a url and serialise
XML to a url, they're XML specific - getURL/postURL isn't, and very, very
much should not be, provide people with the most general tools they need,
only then start with going more specific.

> DOM3 L&S also offers some functionality that does exist in SVGWindow
(e.g.
> synchronous downloads)

We definately do not want synchronous downloads in client-side svg -
javascript is single threaded event driven, synchronous downloads are a
_very_ bad idea in such an environment.

Jim.

Received on Sunday, 1 December 2002 13:53:14 UTC