Re: several messages

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

Received on Friday, 7 April 2006 01:35:30 UTC