W3C home > Mailing lists > Public > www-svg@w3.org > December 2002

Re: SVG 1.2 - SVGWindow

From: Niklas Gustavsson <niklas@protocol7.com>
Date: Sun, 1 Dec 2002 20:11:53 +0100
To: www-svg@w3.org
Message-ID: <asdn1u$d0q$1@main.gmane.org>

"Jim Ley" <jim@jibbering.com> wrote
> "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.

Well, since EcmaScript is the required language that a dynamic SVG viewer
must support I think that it is perfectly fine to be specific for that.

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

Yes, the different types of documents clearly need to be handled
differently. Still, I think it is very important to have a well defined
entry point. Today we don't and in SVG 1.2 we have it half-ways. Please give
the global object a name.

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

Of course and that's why the different WG hopefully can coordinate their use
cases so that the DOM gets the functionality that SVG needs.

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

Well, that should be a choice for the author, not for the spec writers. And,
far from all SVG is used on the client-side or with EcmaScript

Received on Sunday, 1 December 2002 14:16:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:54 UTC