- From: Victor Kapustin <vak@mail.nw.ru>
- Date: Mon, 8 Mar 2004 12:04:58 +0300
- To: <ernestcline@mindspring.com>, <www-html@w3.org>
Ernest Cline wrote: > Well, first off, for XML documents, which also includes XHTML, > the entire document including gets parsed and loaded before > any scripts are run, so if I am understanding this correctly, no scripts > should be running before the document finishes loading. (Note: This > is not the case for HTML) Agreed. One can adopt this policy for HTML scripting also. But it could be impractical from usability point of view (see futher). > Also, if I understand the XHTML2/ > XMLEvents model correctly., each script is self-contained so that > the creation, deletion, or editing of other <script> elements should > have no effect upon the script itself. Do not agree. The hosting environment (either a user agent or host language or both) may allow different scripts to communicate (say, call functions). From practical point of view one can collect a function library (say, ten thousand lines of javascript) in one script while keepeng event listeners scattered among many small scripts. > The only fly in the ointment is > what if the script tries to modify the node which contains the script? [skipped] > On the other hand, self-modifying code is implementable, > with the original script being kept until it finishes execution, > but that would leave phantom nodes inaccessible via the > DOM and which could greatly complicate an implementation. Please comment on phantom nodes. Script modifying a script node is just one problem deserving a discussion, but not the only one. The other one is script collection initialization. The historical practice is to prefetch some [unparsed] entities (like images) by scripts WHILE the document is being loaded, so when onload event has been fired, all the stuff is here - the scripts are ready to process events immediately, not waiting for dragging needed resources referred with URLs. I just tried to extend the idea to the scripts themselves: I have an alternative either to pollute a document with as many script elements as needed or permit the scripts to load function libraries (as separate scripts) they are dependent on (keeping track on what has already been loaded in some single script that every script is able to communicate). Victor Kapustin
Received on Monday, 8 March 2004 04:04:39 UTC