W3C home > Mailing lists > Public > public-webapi@w3.org > February 2006

Targeted Cross-Document Scripting

From: Doug Schepers <doug.schepers@vectoreal.com>
Date: Sat, 11 Feb 2006 21:19:22 -0500
To: <public-webapi@w3.org>
Cc: <public-cdf@w3.org>
Message-Id: <20060212021924.85DF0BE8B@pillage.dreamhost.com>

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.

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
2) discrete SVG instance -> HTML 
3) discrete SVG instance -> discrete SVG instance

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

For (2), I should be able to call a method, C, in the host document (in this
case, the HTML parent doc, "report.html"). 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.
 
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.

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

There are other scenarios that come to mind (e.g. SVG inside of SVG, HTML
inside of SVG), so any formalized solution should keep those in mind, but
SVG inside of HTML is really the most common scenario, I think.

For the record, I can currently get this working in FF native and IE+ASV3,
for the record, although it's a bit krufty and klugey and browser-specific.
But I don't want this functionality to go away, or be overlooked and
undefined, since I think it is of key importance.

Please advise me on the best way to get this behavior specified and
standardized quickly.

Regards-
Doug

doug.schepers@vectoreal.com
www.vectoreal.com ...for scalable solutions.
Received on Sunday, 12 February 2006 02:19:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:53 GMT