On Apr 6, 2006, at 5:07 PM, Cameron McCormack wrote:
Maciej Stachowiak:
I think "no" should be the right answer too. It seems unfortunate to
tie scripting to (some sense of) presentation, but you definitely
want a Window when you are running script, and not when you don't.
The definition of presentation is also loose enough that it's not
hard to claim it applies whenever you want it to, so long as you meet
all the conformance requirements for a document presented in a
browsing context.
In SVG Tiny 1.2, resource documents (i.e., those loaded because of an
external reference in an svg:use, xbl:import, etc.) will have script
running in them.[1] Each will have its own global object, but isn't
rendered in any way. The concept of a window for such documents
doesn't make much sense.
Thanks for pointing this case out.
[1] http://www.w3.org/TR/SVGMobile12/linking.html#externalReferences
The link you cited says:
"The conceptual processing model for resource documents is that the
document is processed as a complete and separate SVG document
instance. The only difference between a resource document and a
primary document is that the primary document is rendered directly to
the canvas, whereas all **resource documents are conceptually
rendered to an invisible (offscreen) canvas**."
[emphasis mine]
It sounds to me like resource documents should, in fact, implement
DocumentWindow and have a Window object for their global scope, since
conceptually they are presented offscreen (and part of that
presentation may be embedded into visible documents). And arguably
<svg:use> should be considered an embedding element, although that
could be a little weird since multiple <use> elements reference the
same document so it's not clear what frameElement should be.
(What would it mean for a resource document to
navigate to a new location by assigning to location.href?)
Some possibilities:
* No effect; even though the resource document is in an offscreen
browsing context, the elements referencing it reference a specific
document, rather than estabilishing the browsing context.
* All <use> elements are updated to point to the new IRI, as if their
xlink:href had changed.
Note that the SVG uDOM has the same issue:
interface SVGGlobal {
void gotoLocation(in DOMString newIRI);
}
I suggest you raise this issue with the SVG working group.
The only methods of the Window interface that I can see that would
make sense
here are the timer-related ones.
Almost everything in the Window interface has some differently named
equivalent in SVGGlobal, so again I think this is an issue with SVG,
not with Window.
So I am not sure that the connection between script and Window is the
right one.
I still think it is. Although it sounds like you have pointed out
some holes in the design of <svg:use>.
Regards,
Maciej
