tag:blog.infosauce.com,2005:Typo Typo 2006-10-26T21:43:54-07:00 Tim urn:uuid:dacf94ae-5012-42e9-a8aa-00f5fa2c1fcb 2005-09-24T16:08:00-07:00 2006-10-26T21:43:54-07:00

<p><a href="http://dean.edwards.name/weblog/2005/09/busted/">An elegant solution to the window.onload problem in Mozilla and IE.</a></p> <p>Client-side developers have long been frustrated by the shortcomings of window.onload, namely that it takes too long before firing if you want to attach scripts to rework the <span class="caps"><span class="caps">DOM</span></span>, yet you have to wait before the <span class="caps"><span class="caps">DOM</span></span> is parsed before manipulating it.</p> <p>The <a href="http://greasemonkey.mozdev.org/">Greasemonkey</a> chaps solved the problem in Mozilla Firefox by uncovering the proprietary <span class="caps"><span class="caps">DOM</span></span>ContentLoaded event. Now not solving the problem in all browsers would be acceptable, since the other browsers could fall-back to the late firing window.onload, but it’s unrealistic to consider a solution for general web use that doesn’t at least take care of 90% of the market (Windows IE).</p> <p>Ever since the <a href="http://www.quirksmode.org/"><span class="caps">PPK</span></a> mentioned something in his blog about a way to solve it in IE and Mozilla(maybe Safari) in the <a href="http://www.quirksmode.org/blog/archives/2005/06/you_shouldve_be_1.html">@media event entries</a> a number of us have been very excited. We’ve been <a href="http://dean.edwards.name/weblog/2005/02/order-of-events/#comment2370">contemplating the best way to use this knowledge</a> involving complicated schemes requiring behaviors in <span class="caps">IE </span>(.htc files) and waiting for the mysterious “more details to come”</p> <p>Well, the details have arrived, and it seems to make most of the scripts to handle an early firing domloaded event moot. Dean Edwards has delivered an <a href="http://dean.edwards.name/weblog/2005/09/busted/">elegant solution to the window.onload problem in Mozilla and IE.</a> If Safari/kthml, Opera, or any of the other browsers not covered by this are an important enough factor at your site, you might have to still think about an alternative like <a href="http://www.brothercake.com/site/resources/scripts/domready/">brothercake’s domFunction.</a></p> <p>We’re going to just stick with Dean Edwards solution for now and call it good, though. Especially since, according to work done on the sIFR image replacement technique, <a href="http://web-graphics.com/mtarchive/001635.php">Safari won’t layout the page properly until the images are loaded</a> (read the 3rd comment). This means having Safari wait for the window.onload is actually a feature.</p>

<p><a href="http://dean.edwards.name/weblog/2005/09/busted/">An elegant solution to the window.onload problem in Mozilla and IE.</a></p> <p>Client-side developers have long been frustrated by the shortcomings of window.onload, namely that it takes too long before firing if you want to attach scripts to rework the <span class="caps"><span class="caps">DOM</span></span>, yet you have to wait before the <span class="caps"><span class="caps">DOM</span></span> is parsed before manipulating it.</p> <p>The <a href="http://greasemonkey.mozdev.org/">Greasemonkey</a> chaps solved the problem in Mozilla Firefox by uncovering the proprietary <span class="caps"><span class="caps">DOM</span></span>ContentLoaded event. Now not solving the problem in all browsers would be acceptable, since the other browsers could fall-back to the late firing window.onload, but it’s unrealistic to consider a solution for general web use that doesn’t at least take care of 90% of the market (Windows IE).</p> <p>Ever since the <a href="http://www.quirksmode.org/"><span class="caps">PPK</span></a> mentioned something in his blog about a way to solve it in IE and Mozilla(maybe Safari) in the <a href="http://www.quirksmode.org/blog/archives/2005/06/you_shouldve_be_1.html">@media event entries</a> a number of us have been very excited. We’ve been <a href="http://dean.edwards.name/weblog/2005/02/order-of-events/#comment2370">contemplating the best way to use this knowledge</a> involving complicated schemes requiring behaviors in <span class="caps">IE </span>(.htc files) and waiting for the mysterious “more details to come”</p> <p>Well, the details have arrived, and it seems to make most of the scripts to handle an early firing domloaded event moot. Dean Edwards has delivered an <a href="http://dean.edwards.name/weblog/2005/09/busted/">elegant solution to the window.onload problem in Mozilla and IE.</a> If Safari/kthml, Opera, or any of the other browsers not covered by this are an important enough factor at your site, you might have to still think about an alternative like <a href="http://www.brothercake.com/site/resources/scripts/domready/">brothercake’s domFunction.</a></p> <p>We’re going to just stick with Dean Edwards solution for now and call it good, though. Especially since, according to work done on the sIFR image replacement technique, <a href="http://web-graphics.com/mtarchive/001635.php">Safari won’t layout the page properly until the images are loaded</a> (read the 3rd comment). This means having Safari wait for the window.onload is actually a feature.</p> Tim Connor urn:uuid:aa449f06-0ba6-450b-85ee-5a41d3171de2 2005-09-25T16:08:00-07:00 2006-10-22T21:34:44-07:00 <p>He also added a method to handle IE the <a href="http://dean.edwards.name/weblog/2005/09/busted2/" rel="nofollow">other way that has been discussed, using an HTC and ondocumentready,</a> in case anyone has any problems with the “defer” approach.</p>