[Javascript] Poorly documented facet of cross-frame execution

Tue Apr 8 09:26:04 CDT 2003

Dear Peter:

  I'm open to debate on subjects of syntactical niceties within JavaScript: some
of the team that co-developed the various pieces are not in complete agreement on
some of the philosophical issues, so who am i to cast my 5-cents into the pot.

  However, the bit about NOT using the document appendage to the DOM description
of an item in the header is demonstrably true (and will break if you insert it).

  Also, if you write a tree-walk of the elements within a document.form in lieu
of the simple-minded 'alert' I suggested, you'll often discover that some of the
elements really AREN'T there (as I contended).  I'm sure it was the intent of 
the designers that onload work as you suggest it should (and I would dearly like
it to), but there are apparently some issues as to when the object pointers are
queued, and when they are actually placed.  My suspicion is that as soon as all
the object pointers are queued the onLoad event gets triggered, in the naive hope
that by the time the handler actually gets invoked the queue will have finished
placing everything.  Maybe in the days of the 8MHz 80286 AT boxes, but today...

I can't really fault your judgement -- it is what I read in countless JavaScript
references (and found supported in the original RFC's), and is intuitively consistant
with the way the rest of the language works.  Moreover, I believed it myself until
I started working with fairly large and ugly window constructs which somehow didn't
quite seem "finished" when the onLoad kicked in.

While the problem is particularly noticeable when you have multiframe documents,it
works adequately for short and simple demos with only a few objects in each window
and a relatively low latency in the build process.  Also, I've found that dynamic
constructs (in ASP, PHP, JavaScript, etc.) which require extensive calculation to build
accentuate the effect.  Some of this may simply be to the poor signalling methods
between these various languages, and some of it may be due to the streamlined
state-machine model that JavaScript uses -- I don't know, and haven't yet devised
methods for finding out.

>From some preliminary testing, the easiest demos to build are ones in which multi-frame
documents with lots of fields in every frame are used.  The onLoad event gets triggered
(it seems) when every frame is referenced by the parent frameset, and NOT when every
field in every frame document is complete.  Thus, the frames at the bottom of the window
are often only half-done when the event-handler is invoked.  Try it!  You'll see!

-- Dave Lovering  

Peter-Paul Koch wrote:
> 
> 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();
> 
> As far as I understand it has little to do with the BODY tag, but everything
> with the fact that the defined functions are properties/objects of the
> global object in the other frame. The global object is window, or self, and
> in the case of other frames parent.frames['name'] (not that here, too, I
> don't use 'document', though I'm less sure why not).
> 
> As far as I know the HEAD/BODY thing has little to do with the
> window/document difference.
> 
> >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.
> 
> No, it isn't. onLoad fires when all arrays like document.forms and
> document.images have been initialized and are accessible. Though indeed some
> images may not display yet, all elements inside the document are accessible
> onLoad, and that's the point of the event handler.
> 
> --------------------------------------------------
> ppk, freelance web developer
> Interaction, copywriting, JavaScript, integration
> http://www.xs4all.nl/~ppk/
> Column "Keep it Simple": http://www.digital-web.com/columns/keepitsimple/
> --------------------------------------------------
> 
> _________________________________________________________________
> Help STOP SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
> 
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript