Re: Targeted Cross-Document Scripting

On Feb 11, 2006, at 6:19 PM, Doug Schepers wrote:

>
> Hi-
>
> 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:

>
> 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):
>
>  report.html
>    <html ...>
>     <object id="income" data="chart.svg" ...>
>     <object id="expenses" data="chart.svg" ...>
>
>     <script ...>
>      function A() { income.Z( value ); ...}
>      function B() { expenses.Z( value ); ...}
>      function C() {...}
>     </script>
>    </html>
>
>  chart.svg
>    <svg ...>
>     <rect onclick="Y()" ... />
>
>     <script ...>
>      top.Z = Z;
>      function Z( value ) {...}
>      function Y() { top.C(); ...}
>     </script>
>    </svg>
>
>
> 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

> 2) discrete SVG instance -> HTML

parent.document

> 3) discrete SVG instance -> discrete SVG instance

parent.document.getElementById("income").contentDocument
parent.document.getElementById("expenses").contentDocument


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

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

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


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

> 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. I  
think specifying "parent" will remove the last shred of a reason for  
the CDR spec to exist, though.

Regards,
Maciej

Received on Sunday, 12 February 2006 03:32:24 UTC