Re: JavaScript problem

#1

Matt Kruse wrote:

Quote:

"Grant Wagner" <gwagner (AT) agricoreunited (DOT) com> wrote:
I don't believe that is true is it?

You are, in fact, correct. My mistake, I apologize.
See: http://www.mattkruse.com/cgi-bin/nph-test.pl

It was my understanding that javascript waited until the document was
delivered, then began a pre-scan to execute inline javascript (such as
document.write calls), then build the document tree, then began calling
events. This is apparently not the case

Thanks for putting together a test case. I didn't have time to assemble anything
myself before I replied to your post, but I did want to reply because otherwise
I would have forgotten, so I phrased my reply as a question and provided what I
felt was a reasonable argument. I fully expected to be proved wrong.

Quote:

Also, if what you say is true, you would not be able to dynamically write
content into the <body> while the page is loading:

That's not necessarily true, though. If the browser did a pre-scan of the
document to execute inline javascript, before parsing the resulting html,
document.write calls would still be possible.

I realized that after I posted my reply and you are absolutely correct.

Quote:

I suppose one could argue that the browser doesn't render the results of a
page like that shown above until the connection was closed and the entire
document delivered, but even that doesn't seem to be the case, many
browsers
begin rendering content before the entire document is delivered.

Depending on the browser, though, you may not actually have access to the
contents of the document until the whole thing has loaded. So even using
javascript to call a function which will modify the screen display may not
work, because the whole document object is not yet available until after the
whole thing loads (in some browsers).

Agreed. Quite frankly I find the entire thing an amazing piece of programming. A
Web browser seems like a simple application, but in fact it is quite complex,
having to deal with arbitrary user-interaction with content that is delivered in
an asynchronous environment over an unspecified period of time.

--

Quote:

Grant Wagner <gwagner (AT) agricoreunited (DOT) com

#2

Grant Wagner wrote:

Quote:

Matt Kruse wrote:
snip
That's not necessarily true, though. If the browser did a pre-scan
of the document to execute inline javascript, before parsing the
resulting html, document.write calls would still be possible.

I realized that after I posted my reply and you are absolutely
correct.
snip

I don't think we have to worry about browsers pre-scanning script
elements for document.write calls. As it is there is the DEFER attribute
on SCRIPT elements to provide a "hint" that it would be acceptable for
the browser to continue parsing HTML and leave evaluation the script
till later. Browsers might be expected to be implemented to take the
hint but making a pre-emptive decision about the order of script
evaluation is much more complex than just looking for document.write
calls.

There is the question of recognising a document.write call in a script
element; being aware that an in-line function call was calling a
function (possibly from a preceding script and possibly indirectly
and/or conditionally) that used document.write. But even an inline
document.write call would necessitate tracing the code that included the
document.write call back to ensure that it wasn't dependent on functions
or variables set-up by preceding script elements that had not included a
document.write statement themselves, and then being in a position to
identify and execute those scripts prior to the one in which the write
statement occurred.

Knowing enough about preceding scripts to identify which of them
subsequent scripts were dependent upon (and how) would probably take as
much work (if not more) as executing them as they were encountered.
Leaving little to be gained by attempting the pre-scan.

Overall it has got to be easier to leave it to the script author to use
the DEFER attribute to flag the scripts that don't need immediate
execution and just assume that every other script needs to be evaluated
in context.

Richard.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Re: JavaScript problem

Javascript JavaScript language (comp.lang.javascript)

Re: JavaScript problem - 04-02-2004 , 10:53 AM

Re: JavaScript problem - 04-03-2004 , 09:14 AM