3
votes

I'm developing a platform for developing desktop apps with web technologies. In the course of doing so I've been trying to get some document/on-ready functionality working with the browser I will be integrating into the platform. That's why I'd previously asked this this question here on SO: javascript-framework-that-primarily-provides-just-document-onready-functionality

However I've not been able to get my browser of choice (shush, its a secret ;) to successfully utilize the functionality suggested by the one and only answer to the above. So, in the course of just trying to figure out what might possibly work I stumbled upon the following.

The code below has the same effect within this browser I'm using simply by executing a function after a timeout of 1 millisecond: I can write to the DOM while the big image is loading. This might not be the ultimate solution for me, I may write something specific to how DOM functionality is implemented by the Javascript engine for this browser.

Nevertheless, I decided to see if this works in standard browsers, and much to my surprise, it does! In light of which, my question: are various implementations of dom/readiness functionality provided by various Javascript frameworks, simply overkill?

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<script>
setTimeout(function() {
    var txtNode = document.createTextNode("ready_yet?");
    var ready_yet_el = document.getElementById("ready_yet");
    ready_yet_el.appendChild(txtNode);
},1);
</script>
</head>

<body>
<div id="ready_yet"></div>
<img src="http://www.ryanmorr.com/tests/ondomready/pic.jpg" />
</body>

</html>

EDIT/FURTHER THOUGHTS On the page linked to by the answer to my previous related question it states "For Firefox and Opera a simple check of event type will determine if it is DOMContentLoaded. Safari and IE will check against the document’s ready state....Finally in case all else fails, the onload event will bring up the rear." Perhaps a setInterval similar to my setTimeout above could be the penultimate course of action, before relying on onload as a last resort? In any event, with the embeddable browser I've chosen, neither the DOMContentLoaded event, nor document.readyState appear to be supported.

3
Your example works because (as you may know) the timeout function is called after the div has been parsed, a much less hacky version would be to have the script run (without timeout) after the div has been closed, not a specification but all browsers will make a dom node available before it continues to parse the xml/html nodes (or at least available before the next dom element is fully read and executed).meandmycode
Me thinks the answers you got in the first 3 hours only read the title of the question. They all say "No, it's bad to run scripts before the DOM is ready".Crescent Fresh
I expected to be dealt with even more harshly ;) But to get confirmation of my instincts, even with references showing others had "beaten me to the punch", is just what I was looking for, and allows me to continue to proceed down this path with a certain level of confidence; next I will see if CSS selection frameworks such as Peppy or Sizzle will work with this particular browser implementation.Dexygen

3 Answers

4
votes

Your hunch is good and well founded IMO. But someone has beat you to the punch already. Short answer is that setTimeout is not a working implementation of detecting DOM readiness in all cases. It may be ok for your browser of interest, but IE fails in some situations.

It may interest you to know that Microsoft's own ASP.NET AJAX framework uses the setTimeout trick to detect DOM readiness. And surprise, surprise: it fails in certain use cases as well.

In short, the problem seems to lie in IE with slow loading scripts, either due to large file size (eg ~500K) or network/server latency.

3
votes

No, because when DOM 'unreadiness' bugs manifest they do so in incredibly unusual and difficult to predict and track down ways - each one (of course) unique to the browser that it happens in.

It's much easier to just avoid those issues entirely and know that you're always going to be dealing with a ready DOM.

As an example, a while ago I had an DOM not ready bug in everyone's favourite browser than manifested itself by working perfectly 99% of the time, but died with errors if the page content had an img element with src attribute in it AND if the content also had a ul element with any number of li's within in...it didn't bug if any of those things weren't true.

It's easy for me to say now 'oh it was a DOM issue' but at the time...no, not so easy.

0
votes

Simply, no. Someone with a slower connection and multiple files to load will not appreciate their browser trying to run scripts on elements that don't exist yet.