RE: Targeted Cross-Document Scripting

Hi, Maciej-

Thanks for your response. I'll reply inline. 

Maciej Stachowiak wrote:
| 
| On Feb 11, 2006, at 6:19 PM, Doug Schepers wrote:
| 
| > I have a common and important use-case, but after reading through  
| > the CDF
| > and WICD specs, I couldn't see how this is covered. It may be that  
| > this is
| > something that should be handled by WebAPI (in which case 
| I'm happy  
| > to own
| > it), but it should definitely be coordinated with CDF. This is  
| > notable,
| > since CDF is in LC.
| 
| I think your use case is already covered by existing HTML and SVG  
| specifications and implementations:

I don't. I think that there are some klugey ways you can cobble it together,
but I don't think it's consistent across implementation, nor is it properly
specified. I think that this will be an increasingly common use-case, so I
think it behooves the W3C to standardize it.


| > To be concrete, I have a single HTML document with 2 references to  
| > the same
| > SVG file. Here is a pseudocode example (please ignore or improve  
| > syntax):
[...]
| >
| > There are three useful ways which I would like to see these  
| > independent
| > script blocks interacting:
| > 1) HTML -> discrete SVG instance
| 
| document.getElementById("income").contentDocument
| document.getElementById("expenses").contentDocument

In what UA does this work? I tried it in both FF and IE+ASV (Windows), but
it was not functional, with either <iframe>, <embed>, or <object>.


| > 2) discrete SVG instance -> HTML
| 
| parent.document

This does not cover the use case I describe below.


| > 3) discrete SVG instance -> discrete SVG instance
| 
| parent.document.getElementById("income").contentDocument
| parent.document.getElementById("expenses").contentDocument

As above, I could not get this to work.


| > For (1), the HTML should be able to get a reference to a specific
| > instantiation of the SVG (the "data" for one particular <object>  
| > element),
| > and make a method call to that particular instance (so, I could  
| > send values
| > to the chart representing either "income" or "expenses").
| 
| Yep, already doable, they create separate document objects which may  
| be addressed via contentDocument on the referencing element.
| 
| > For (2), I should be able to call a method, C, in the host 
| document  
| > (in this
| > case, the HTML parent doc, "report.html").
| 
| Already doable.

As I said in my original email, yes, it's doable. However, to the best of my
knowledge, it is not specified. As an author, I don't want to fork code and
rely on UAs to be consistent across OSes and version, when there is no
guiding specification to follow.


| > Further, the particular instance that made the method call should  
| > be accessible in the API of the call, i.e.
| > an object "caller" that contains both the name of the 
| function that  
| > called
| > the current function, and the element reference of the 
| instance. In  
| > the
| > above example, if function Y in the "expenses" object 
| instance called
| > function C in the host document "report.html", inside function C,  
| > there
| > would be a "caller" property something like this:
| >  caller.function = function Y();
| >  caller.instance = [object HTMLObject] > id="expenses";
| >
| > This is necessary since I would want to know if the user 
| clicked on  
| > a bar in
| > "income" or "expenses" in order to take the correct action 
| in the host
| > document.
| 
| I disagree with this. If you want to pass caller information, you  
| need to pass it as a function parameter. Making a function call  
| should not implicitly pass magical information.

It's not magical. It's pragmatic, and has an analog in other languages. In
JavaScript, it would be similar to "arguments". I am not demanding this
particular mechanism, but I do think the functionality to do this should be
there somehow.


| > Ideally, since both "parent" and "top" are a bit overloaded in  
| > terms of
| > functionality, the scope resolution operator inside an instance  
| > document
| > would actually be something like "host" (so "host.C()" would reach  
| > function
| > C in the HTML document); similarly, you could have different  
| > terminology for
| > the embedded file, such as "instance". There should also be  
| > graceful and
| > defined behavior for what happens when "chart.svg" is encountered  
| > outside of
| > its host document, such that "host.C()" could not be resolved.
| 
| "parent" is not overloaded, it means the parent global object. This  
| has been de facto true in HTML UAs forever, and is proposed to be  
| specified for SVG in SVG Tiny 1.2. The term "host" is often used to  
| mean hostname so I think it would be more confusing. There's no need  
| IMO to replace the existing properties.

Well, there are SVG UAs where "parent" does not work (specifically,
ASV6pr1), though "top" does. 

The keyword "host" was just a suggestion, as I felt it was more descriptive
of the actual relationship of between the documents, but the syntax is not
that important to me. What is important is that something is officially
specified, including what happens when a call is made to a method in a
parent doc, and either that function or the parent doesn't exist.


| > (3) is more of an edge use-case, and would be harder to define  
| > outside of
| > the context or a host document, so there might merely be a bridge  
| > or routing
| > function in the HTML document, e.g. "function D( parameters ) 
| > { expenses.X(
| > parameters ); }" or "function D = expenses.X". This would not  
| > require any
| > special definition, but it would be useful as an informative note to
| > describe how this can be done.
| 
| You don't need a bridge, it can already be done with existing  
| implementations in an interoperable way. Unless I am missing  
| something major here.

Yes, it can be done. I think it is the role of specifications not only to
normatively define how something should be implemented, but also to
informatively describe best practices and practical use cases. This is what
I'm asking for for (3).


| > Please advise me on the best way to get this behavior specified and
| > standardized quickly.
| 
| The main missing thing that is not yet standardized is the "parent"  
| property of the global object. I believe Web API will do this. 

The thing that comes closest to this in the WebAPI charter is "An API
specification for a client interface", which only specifies "Window". I'd
rather not leave it up to chance that "parent" (or whatever) is also
specified.

For the record, my working example is here:
  http://svg-whiz.com/svg/instances/

To get this to work, I had to fork my code, and to pass each instance a
unique identifier from the parent HTML, that was passed back as a parameter.
I think that's remarkably inelegant, and it did not consistently work for me
outside the limited confines of this test code.


Regards-
Doug

doug.schepers@vectoreal.com
www.vectoreal.com ...for scalable solutions.

Received on Sunday, 12 February 2006 07:27:51 UTC