Side note:
> Thanks so much guys, very helpful discussion... (and they say
> Mootoolers are snobs! pfff)
It's interesting this stigma still exists... I wonder what a communities gotta
to do get rid of this.
- Chase
On Jul 29, 2011, at 1:19 PM, Paul Schwarz wrote:
> 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 $).
