Back Button/Onload Mess
Working on some code earlier this week, I discovered that Opera doesn’t fire the load event when navigating to a page using the back button. This means anything set to fire onload doesn’t get executed…so much for good coding practices. But this issue appears to intermittently happen on other browsers too, notably Firefox and Safari (Internet Explorer fires load no matter what).
Really, there should be some standard way of determining when the DOM document has been completely created and is ready to be used versus the load event, which only tells us after everything on the page has been loaded. (This is where the YUI‘s onAvailable() method comes in really handy.) There actually are a mishmash of ways to do this otherwise, but no way that is common across all browsers:
- Using the
<script>element’sdeferattribute. By adding this attribute, you instruct the code not to be run until the document has been completely loaded. This works in most browsers, but can be a pain because you need to figure out which code needs to be run after the document is complete and separate that out into a distinct JavaScript file (defer) only works for external files, not inline scripts). - Use the document’s
DOMContentLoadedevent. This is supported by Firefox and Opera (starting in version 9). This event fires when the document is completely loaded. I can’t find anything saying that this is a standard right now, but it works. - Internet Explorer’s
documentobject supports areadystatechangeevent that fires whenever the document’sreadyStateproperty changes. This is different from using an XML DOM object in that it returns strings…you want to look for “complete” as a value to determine when the DOM is ready for manipulation. - Apparently, Safari supports the
readyStateproperty on a document but has no event for watching it, therefore you could set a timeout to watch for it to change. - Dean Edwards also suggests another approach using Internet Explorer’s behaviors.
All of this adds up to major pain in the butt. Then again, I just keep telling myself, all of these differences is why people like me have jobs. If it all worked the same everywhere, we’d have far less value than we do.
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
Both comments and pings are currently closed.




7 Comments
Yes thats true. I felt the same way when I was learning CSS, which is such a pain. With that said, I guess there should be a balance when it comes to following standards and just doing your own thing. For example, I really like creating my own attributes in html tags
<p my="YouSayWhyandIsayWhyNot"></p>
aaron on June 28th, 2006 at 1:08 am
There is a follow-up to the original Dean Edwards’ post http://dean.edwards.name/weblog/2006/06/again/
Alexei on June 28th, 2006 at 11:02 am
Does <script defer> really works for anything other than IE?
Alexei on June 28th, 2006 at 11:09 am
Alexei – you’re right, only Internet Explorer supports the defer attribute (funny how they are the only ones who support the standard). And I do already have that link in the main post.
Nicholas C. Zakas on June 28th, 2006 at 8:43 pm
Firefox 1.5 has a new page caching architecture that indeed usually results in the load event respectively the onload handler not being fired when the back or forward navigation is used.
There are new events however, pageshow and pagehide, which can be used, see
<http://developer.mozilla.org/en/docs/Using_Firefox_1.5_caching>
Martin Honnen on July 1st, 2006 at 10:01 am
Thanks for the link, Martin. I believe Opera’s caching mechanism is similar (though without the helpful events Firefox provides).
Nicholas C. Zakas on July 1st, 2006 at 6:41 pm
Check this page out:
http://www.thomasfrank.se/when_onload_fails.html
richard m on July 16th, 2006 at 1:01 pm
Comments are automatically closed after 14 days.