{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.manongdao.com/data/attach/logo/logo.png', '推荐 唯我独甜 的问题《Is checking for the readiness of the DOM overkill?》','https://www.manongdao.com/q-1197610.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
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.
Your hunch is good and well founded IMO. But someone has beat you to the punch already. Short answer is that
setTimeoutis 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
setTimeouttrick 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.
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.
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.