[Javascript] Poorly documented facet of cross-frame execution

Mon Apr 7 10:22:11 CDT 2003

A number of folks have been alluding to coding structures that require invoking routines across frames (parent/child, child/parent, peer/peer), including IFRAMEs.  One of the elements that seems to be missing from the standard documentation and the
JavaScript/JScript RFC's (including the W3C state model) is the fact that when invoking JavaScript one must consider the placement within the target frame as to how one addresses it.

For example, if we have two peer frames (frameA and frameB), each containing mycode1.html and mycode2.html respectively, and it is intended that mycode2.html invoke a JavaScript routine 'foobar()' which exists in a <script
language='JavaScript'>...</script> block in the header of mycode1.html, the following will NOT work:

  parent.document.frames["frameA"].document.foobar();

The reason is that the 'document' object in frameA's code module doesn't REALLY begin until it hits the <body> tag.  The correct procedure is therefore

  parent.document.frames["frameA"].foobar();

Similarly, if mycode1.html wants to invoke a javascript routine 'foobar2()' in the body of mycode2, the following SHOULD work:

  parent.document.frames["frameB"].document.foobar2();

The reason I say SHOULD is because some browsers follow the canonical but absurd belief that javascript modules should only be defined and/or src'd in the header block.  I've not had the time to test every rev of every browser out there, but I have seen
discrepancies in behavior related to this.

In fact, the whole premise that <head> and <body> serve as the preparation and display blocks of DHTML code is starting to erode, as JavaScript, ASP, PHP, etc. can mingle set-up and execution elements throughout the whole document.  Some folks prefer to
do their primary JavaScript coding AFTER the </html> tag with the naive but charming premise that the whole document has finished loading by that point!  [Don't you believe it -- DHTML behaves as though it were multi-threaded code!].

--------------

On a related subject, the erroneous assumption that onLoad correctly denotes the completion of the entire screen build can be easily tested by simply putting an onLoad='alert("done loading...")' declaration at the end of the <body> tag.  Unless you're
dealing with some incredibly wimpy window, the alert will come up ALWAYS with part of the screen still undefined.  All those objects which have yet to be painted (which may NOT be merely jpegs and the like, as certain-people-who-will-remain-nameless
suggested earlier) cannot be referenced by any code within the routine pointed to by the onLoad event.  In short, onLoad is broken.

I am given to understand that Netscape/Mozilla and perhaps Opera are nearly done fixing the code to properly handle this, but M$oft is still out in the weeds somewhere.

-- Dave Lovering