Targeted Cross-Document Scripting

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Targeted Cross-Document Scripting

Doug Schepers-2

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

[hidden email]
www.vectoreal.com ...for scalable solutions.


Reply | Threaded
Open this post in threaded view
|

Re: Targeted Cross-Document Scripting

Maciej Stachowiak


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


Reply | Threaded
Open this post in threaded view
|

RE: Targeted Cross-Document Scripting

Doug Schepers

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

[hidden email]
www.vectoreal.com ...for scalable solutions.
 


Reply | Threaded
Open this post in threaded view
|

RE: Targeted Cross-Document Scripting

Doug Schepers-2
In reply to this post by Doug Schepers-2

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

[hidden email]
www.vectoreal.com ...for scalable solutions.
 


Reply | Threaded
Open this post in threaded view
|

Re: Targeted Cross-Document Scripting

Maciej Stachowiak
In reply to this post by Doug Schepers

On Feb 11, 2006, at 11:27 PM, Doug Schepers wrote:

>
> 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.
The following much simpler code works in Safari (with a WebKit  
nightly, that's the only versions with SVG support so far) Opera 9  
and Firefox 1.5:





I don't have Win IE + ASV to test with but I suspect it would work  
there too.

This relies on three things that are not currently standardized:

1) contentWindow property of the <object> and <iframe> elements in HTML
2) frameElement property of the global object
3) parent property of the global object

But I think all three are interoperably implemented in major UAs.

The CDR proposed document.referencingElement would replace the need  
for 2.

referencingElement + contentDocument could replace the need for 1 if  
you attached the functions to the document instead of the global object.

Regards,
Maciej


Instances.html (1K) Download Attachment
masterFile.svg (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Targeted Cross-Document Scripting

Doug Schepers

Hi, Maciej-

Maciej Stachowiak wrote
|
| The following much simpler code works in Safari (with a WebKit  
| nightly, that's the only versions with SVG support so far) Opera 9  
| and Firefox 1.5:

Thanks for your example. As we discussed offlist, however, this does not
work at all in WinIE+ASV3, which is still a very common combination. Though
this may be because it is a plugin, or because <object> is broken in IE,
this only underscores the need for such interfaces to be specified.

Unless it's defined and specified, there is no clear way for implementors to
decide how to do it, if they even think of it; and there is less leverage
for users and authors to pressure implementors to do it a certain way.
Defacto standards are great when they are interoperable, but they are a
major pain when not.

I do concede the point that passing an argument from the calling instance
function, rather than having an implicit caller property, is a more elegant
solution, but this is only so if "self" is indeed specified.

Regards-
Doug
 


Reply | Threaded
Open this post in threaded view
|

Re: Targeted Cross-Document Scripting

Jim Ley-2
In reply to this post by Maciej Stachowiak

On 2/12/06, Maciej Stachowiak <[hidden email]> wrote:
> I don't have Win IE + ASV to test with but I suspect it would work
> there too.

unfortunately not as the SVG is in an EMBED element inside the IFRAME
- so it could be made to work there with some extra indirection, I
don't think there's any way to make it work with OBJECT in the above
scenario.

> referencingElement + contentDocument could replace the need for 1 if
> you attached the functions to the document instead of the global object.

Attaching functions to the document would be a bad idea though I
think. In IE you can even make it actually impossible, and many less
common UAs have similar problems. (Notably the Java ones including the
Batik/IceBrowser CDF combination I believe, but haven't checked)

Cheers,

Jim.

Reply | Threaded
Open this post in threaded view
|

Re: Targeted Cross-Document Scripting

Cameron McCormack-4

Maciej Stachowiak:
> > referencingElement + contentDocument could replace the need for 1 if
> > you attached the functions to the document instead of the global object.

Jim Ley:
> Attaching functions to the document would be a bad idea though I
> think. In IE you can even make it actually impossible, and many less
> common UAs have similar problems. (Notably the Java ones including the
> Batik/IceBrowser CDF combination I believe, but haven't checked)

Indeed Batik doesn't support setting arbitrary properties on host
objects (and it isn't required to).  Attaching functions and other
script objects could be done with DOM 3 user data on the document node.

--
 Cameron McCormack ICQ: 26955922
 cam (at) mcc.id.au MSN: cam (at) mcc.id.au
 http://mcc.id.au/                        JBR: heycam (at) jabber.org


Reply | Threaded
Open this post in threaded view
|

RE: Targeted Cross-Document Scripting

Ian Hickson
In reply to this post by Doug Schepers

On Sun, 12 Feb 2006, Doug Schepers wrote:
>
> Thanks for your example. As we discussed offlist, however, this does not
> work at all in WinIE+ASV3, which is still a very common combination.

Problems with individual implementations is not in scope for these lists,
as far as I can tell. In particular, specifying new stuff won't help with
that problem.

(I agree that de-facto standard interfaces should be specced.)

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'