- Powered by Domino 8.5.2 Domino Accelerator Pack
- Accelerate your web applications
Lotus Triple Search DominoExperts + Blogs + R8 forum -> Script vault -> JavaScript

 DomLoaded - Which one is best?

Tomas NielsenPost date: 2007-08-25 16:59

I am trying to read up on the "DomLoaded" or "onDomLoad". There are quite a lot of scripts out there.

Dean Edwards did som early work on it but has anything happened after that?

Tomas NielsenPost date: 2007-09-15 23:52

It seems like there is no reliable way to use the DOM in IE before onload.

Dean's way of doing it fails for large documents if you mix in document.write in the equation.

Joacim BoivePost date: 2007-09-20 09:01

Well, I personally have never seen an actual use for document.write. Better  to get a handle to a placeholder and then update .innerHTML. If you need to dynamically load scripts then create a script-element with the DOM and add it to the head-tag (appendChild), this trigger the lib to execute immediately.

Dean talks about jslibs as it's a bad thing, that's very typical of Domino developers for some reason. Separation is the key: non intrusive JS, css libs, js libs etc. HTML for presentation and nothing else...


I recently semi-optimized a page that was written in the traditional Domino way. Using the JS Header tag, inline JS, inline CSS, images to draw lines, spacer gif's etc. I would have like to convert the tables to a div-layout but I didn't have the time. But still I saved 11% of the page size, reduced the number of CSS errors from 86 to 6 and it know works in all browsers (Only worked in IE previously)...

The biggest difference though was the time it took to load the page. I reduced the page load time by 50%! From my experience you can reduce the page size by around 40-50% by using a DIV-layout instead of a table layout and it will render much faster. But that's a different story...


Sorry for my rambling on. ;)



Tomas NielsenPost date: 2007-09-20 21:02

Nice to see you're back Joacim!

document.write has its advantages when you do not have full control of the page rendering process.

My problem is that I want to start manipulating the DOM before all page elements are loaded. The onload event is triggered too late for my application.

This works fine in FF but Internet Explorer has no good way of handling this. I can get it to work in 90% of the cases but it fails BAD in some cases - "The page can not be displayed" stopping the whole page loading process.

Joacim BoivePost date: 2007-09-24 08:16

Usually there's another approach then document.write. I try and stay away from it as far as possible..

I have a solution to trigger script as soon as the DOM is loaded both on Mozilla (DOMContentLoaded) and IE. I also catch all remaining browsers with the traditional onload approach.


I've written a small article for our intranet (in Swedish) with an example database.

I do have the example database written by me with comments in english. It's fairly simple really...

Have a look at the poc-page element for details.


Fredrik StöckelPost date: 2007-09-27 20:22

I think  this (at the bottom of the page) is the latest proposal of the domLoaded variants. It seems to work pretty well. You can see it in action here.

Tomas NielsenPost date: 2007-09-27 21:36

It looks like some of Deans code but with a twist.

I have tried using:

/* for Internet Explorer */
/*@cc_on @*/
/*@if (@_win32)
 document.write("<script id=__ie_onload defer src=javascript:void(0)><\/script>");
 var script = document.getElementById("__ie_onload");
 script.onreadystatechange = function() {
  if (this.readyState == "complete") {
   DOMReady(); // call the onload handler
/*@end @*/

As I said it works most of the time but it is not 100% safe.
The problem that occurs is also described here:

There exist a bug report at microsofts site but I can not find it now.

Tomas NielsenPost date: 2007-09-27 21:43

Sorry Fredrik I did not see you response before posting, I started the post some hours ago but did not have time to finish it. 

I will look into you suggestion! That one seems to have a completely different approach!

Joacim BoivePost date: 2007-09-28 08:51

The key is to have a separate scriptlibrary for IE only, which none of the other solutions you refer to seem to have.

The link you present to uses inline javascript which is a big nono and simply bad form. Have a look at behaviours and unintrusive javascript..

If you find my solution not to work in some instances I love to hear about it, that does exclude solutions for "malformed" html pages. HTML is for presentation only, functions in libraries and external stylesheets for the layout. In XHTML 2.0 you won't have any choice, so you're better of getting used to it right now... ;)


Tomas NielsenPost date: 2007-09-28 11:26

You have a point there, Joacim, about bad formed HTML pages. The situation my script did not work was in an extreme situation with a page with lots of external widgets, document.write, iframes and all sorts of bad things. 

I am now trying out the new "Gimmarchi" approach. I would love to have something that would survive even in extreme situations with IE.

Fredrik StöckelPost date: 2007-09-28 20:30

The original "doScroll" solution came from this guy and is an IE solution only and is supposed to be more safe. According to this Ajaxian thread, jquery will incorporate a similar approach.

dperiniPost date: 2007-10-05 10:28


thank you for pointing to my original solution with the doScroll('left') trick, I appreciate that. It seems that many people have been confused by Hedger Wang and Stuart Langridge.

The solution somehow slipped from my hands and was used by fellows around as soon as they got their hands on it. Unfortunately the modifications that where applied (by others) did not exaclty work as expected.

My concern is about the bad feeling people will have when they try the modified versions...

Unfortunately I cannot do anything about that, just hope they will realize soon.

If your are going to use it and need help or just want to make some question about IEContentLoaded and its usage I will be happy to answer your questions.


Tomas NielsenPost date: 2007-10-05 15:27

dperini, welcome here!

And sorry for confusing your original work with others. There is such a buzz around this that it is hard to follow all the threads.

I am now using your doScroll('left') method and I could prove that my problem page do work with your method where it did not work with Deans code. So I must take back my earlier claim that there is no reliable way of determining this for IE.

Now there is!

dperiniPost date: 2007-10-05 19:51

Hej Tomas,

I hope it can fit your needs as for everybody else.

It is important to note that the "document.onreadystatechange" event that I use as part of the complete IEContentLoaded solution is absolutely necessary. There are a number of documented cases where it will not work without it, one example is when there are no images in the page.

Other cases that will be catched by the "document.onreadystatechange" event are for example all those edge cases where the page is reloaded from the internal browser "cache" (Back/Forward, Alt+Arrow Left/Right, Menu & ContextMenu Refresh etc.)

As I said in my comments on the original test-case page the IEContentLoaded should be used in combination with Dean Edwards code covering the other browsers/platforms.

Hav det godt !!!


Dennis PaulsonPost date: 2008-02-16 12:33

Update in the matter

Stuart Colville recently suggested to use setTimeout(loaded, 0) here:

But it seems like it only works with content delivered with gzip as described here:

It is a very easy solution IF you use gzip. Otherwise it is a dead end.

For Domino - lacking gzip - do not bother.

dperiniPost date: 2008-03-14 19:39

Sorry but that cannot be thought as a viable solution. A timer is still a timer not an event.

The load process is quite more complicated than what the try to say and demonstrate.

As a first annotation, they did not understand that their method will not work without a server...

Not to mention that the "onload" problem is mostly broken when the browser decide to use it's internal cache, so when you hit Back and Forward buttons for example, but really in many more cases too, in those cases the file is not retrieved from the net but from the local disk and that will make a big difference for the detection strategy.

The "IEContentLoaded" trick does not suffer the same restrictions, the content may be gzipped or not, the real page and javascripts may reside on a local disk or CD-ROM, no server is required....

A big you agree ?


Diego Perini


RSS feed
Subscribe to Forum

Share this page

Top posters
Tomas Nielsen212
Joacim Boive27
Fredrik Stöckel27
Niklas Waller13
Kenneth Haggman11
Bryan Kuhn10
Daniel Lehtihet9
Jonas Israelsson8