halo, As i understand it, "A browser window has a single thread that performs parsing of HTML, dispatching of events and execution of JavaScript code." does that mean then, a page that is loading and still being parsed will pause this parsing when either i)a script block is found and executed and ii)an event that triggers a javascript event handler is being executed thanks, j.
"A browser window has a single thread that performs parsing of HTML, dispatching of events and execution of JavaScript code." I do not belive that is correct. As you allude to yourself, the page does not freeze while you excecute event handlers. There is also setTimeout() which implies threading. On the initial load what you wrote may be true. <body> <script> long function </script> <img /> <body> The img will probably not showup untill the script is done. But after that js is "multi-threaded" or it can at least handle asynchronous requests.
i got my quote from the following: http://dev.opera.com/articles/view/timing-and-synchronization-in-javascript/"]http://dev.opera.com/articles/view/timing-and-synchronization-in-javascript which does suggest the situations in my first post. timeouts are events, which are queued (by the browser) and handled sequentially by the thread that controls the page, which also apparently handles parsing. if the page control is indeed single threaded and handles the above, an event, say timeout or click, could pause the page load (parsing).
Technically parsing doesn't pause when a <script> element is come across, the <script> element gets parsed. If it's a large script element or does alot of things it could take awhile to parse which could seem like it's pausing the parsing of the page. There's also external <script> elements, technically, loading them from the server is part of parsing & again can make it seem like parsing is being paused, this is the reason behind the "defer" attribute of <script> elements which point to external scripts, "defer" tells the browser to wait untill everything else is parsed then come back & parse the <script> element. Once the page has been parsed it turns into somthing like a boobytrap, just waiting for somthing to happen. The exact method each browser uses to monitor triggers/events varies, but they all amount to pretty much the same thing as a 5 year old in the back seat of a car asking "Are we there yet ?" over & over. Opera is a good place to pay attention to, they're one of the handfull of browsers that pass the ACID2 Standards Compliance test.
hi, brilliantly explained joebert. by the way, I meant the html parsing is paused but as you say, it seems like the page isn't loading. My main concern with this is events at page load time. i understand how inline and external script blocks are dealt with and i understand how events are dealt with once the page is loaded - the 5 year old questioning but halfway through loading a page (say its a slow connection) a user can click on a button, or a timeout could be triggered. if the event handlers are triggered, lets say after the parsing of the next element or whatever, then the supposedly single thread would be diverted and parsing would stop whilst the event is dealt with. is that a reasonable idea of what happens? it's this middle ground i'm unsure of, where the browser is both event driven and sequentialy loading a document. i suppose the event could be queued until the page is loaded fully, but i have read that the event handlers can pause the parse to give a quicker response.