Great, thanks for the </body> tip. And Philip, no I don't support IE6
at all! ;-) but the example I gave is valid, i.e. the DOM could easily
throw exception if you ever tried to modify an element that it's still
trying to render, the reason why most people don't experience this is
they wouldn't ever want to try it, it's pointless, all I'm saying is
that IE6 will actually crash and close!!
Another options I thought of which I am actually using to great effect
is to use the singleton pattern and then when I use the logger I just
call Logger.instance().debug('my message') for example. It means that
the actual app code can hook on the domready event and then ask for
the Logger instance which will be lazily created (once) on demand, so
there is no race condition in the bootstrap code. I like this solution
very much because you feel in total control instead of trying to
leverage the life cycle of the loading of a page in a browser. I'm not
suggesting that your solutions above aren't correct, I just think that
insofar as this pattern can be applied it feels clean and safe.
Thanks so much guys, very helpful discussion... (and they say
Mootoolers are snobs! pfff)
On Jul 27, 9:01 am, Olmo <[email protected]> wrote:
> Putting your script tags at the end of the body is best in terms of
> rendering time. IE and other browsers block rendering until the script src
> is loaded and evaluated. Since it's at the bottom before the body end tag,
> everything else above is rendered.
>
> I don't think you'll find yourself within a <table> if you're right before
> the end </body> tag.
>
> And again, since all elements have been parsed/created/rendered by the
> browser it's accessible via document.getElement (or $).
