What exactly is the difference between the window.onload event and the onload event of the body tag? when do I use which and how should it be done correctly?
-
2you should use " to surround the attribute valueSven Larson– Sven Larson2010年04月10日 16:25:21 +00:00Commented Apr 10, 2010 at 16:25
13 Answers 13
window.onload = myOnloadFunc and <body onload="myOnloadFunc();"> are different ways of using the same event. Using window.onload is less obtrusive though - it takes your JavaScript out of the HTML.
All of the common JavaScript libraries, Prototype, ExtJS, Dojo, JQuery, YUI, etc. provide nice wrappers around events that occur as the document is loaded. You can listen for the window onLoad event, and react to that, but onLoad is not fired until all resources have been downloaded, so your event handler won't be executed until that last huge image has been fetched. In some cases that's exactly what you want, in others you might find that listening for when the DOM is ready is more appropriate - this event is similar to onLoad but fires without waiting for images, etc. to download.
4 Comments
myOnloadFunc() in the global context (this will refer to window). Setting it via javascript will make it execute in the context of the element (this refers to the element the event was triggered on). In this particular case, it won't make a difference, but it will with other elements.this refers to if desired.There is no difference, but you should not use either.
In many browsers, the window.onload event is not triggered until all images have loaded, which is not what you want. Standards based browsers have an event called DOMContentLoaded which fires earlier, but it is not supported by IE (at the time of writing this answer). I'd recommend using a javascript library which supports a cross browser DOMContentLoaded feature, or finding a well written function you can use. jQuery's $(document).ready(), is a good example.
8 Comments
window.onload can work without body. Create page with only the script tags and open it in a browser. The page doesn't contain any body, but it still works..
<script>
function testSp()
{
alert("hit");
}
window.onload=testSp;
</script>
6 Comments
<!ELEMENT html (head, body)> [1] - and html401 specifies <!ELEMENT HTML O O (%html.content;) with <!ENTITY % html.content "HEAD, BODY"> as well [2]. html51 states A head element followed by a body element. for html content as well. [3] w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict w3.org/TR/html51/semantics.html#the-html-element -- So I guess all of those common/in-use HTML standards do require a body tag. :)Start tag: optional, End tag: optional'so many subjective answers to an objective question. "Unobtrusive" JavaScript is superstition like the old rule to never use gotos. Write code in a way that helps you reliably accomplish your goal, not according to someone's trendy religious beliefs.
Anyone who finds:
<body onload="body_onload();">
to be overly distracting is overly pretentious and doesn't have their priorities straight.
I normally put my JavaScript code in a separate .js file, but I find nothing cumbersome about hooking event handlers in HTML, which is valid HTML by the way.
5 Comments
I prefer, generally, to not use the <body onload=""> event. I think it's cleaner to keep behavior separated from content as much as possible.
That said, there are occasions (usually pretty rare for me) where using body onload can give a slight speed boost.
I like to use Prototype so I generally put something like this in the <head> of my page:
document.observe("dom:loaded", function(){
alert('The DOM is loaded!');
});
or
Event.observe(window, 'load', function(){
alert('Window onload');
});
The above are tricks I learned here. I'm very fond of the concept of attach event handlers outside of the HTML.
(Edit to correct spelling mistake in code.)
3 Comments
window.onload - Called after all DOM, JS files, Images, Iframes, Extensions and others completely loaded. This is equal to $(window).load(function() {});
<body onload=""> - Called once DOM loaded. This is equal to $(document).ready(function() {});
5 Comments
ready vs onload events. load fires after the entire document is loaded including all scripts, images and stylesheets. DOMContentLoaded fires after the DOM tree has been built but before images etc. Its DOMContentLoaded that has equivalence to document.ready, not load.There is no difference ...
So principially you could use both (one at a time !-)
But for the sake of readability and for the cleanliness of the html-code I always prefer the window.onload !o]
Comments
<body onload=""> should override window.onload.
With <body onload=""> , document.body.onload might be null, undefined or a function depending on the browser (although getAttribute("onload") should be somewhat consistent for getting the body of the anonymous function as a string). With window.onload, when you assign a function to it, window.onload will be a function consistently across browsers. If that matters to you, use window.onload.
window.onload is better for separating the JS from your content anyway. There's not much reason to use <body onload=""> ; anyway when you can use window.onload.
In Opera, the event target for window.onload and <body onload=""> (and even window.addEventListener("load", func, false)) will be the window instead of the document like in Safari and Firefox. But, 'this' will be the window across browsers.
What this means is that, when it matters, you should wrap the crud and make things consistent or use a library that does it for you.
Comments
If you're trying to write unobtrusive JS code (and you should be), then you shouldn't use <body onload="">.
It is my understanding that different browsers handle these two slightly differently but they operate similarly. In most browsers, if you define both, one will be ignored.
Comments
Think of onload like any other attribute. On an input box, for example, you could put:
<input id="test1" value="something"/>
Or you could call:
document.getElementById('test1').value = "somethingelse";
The onload attribute works the same way, except that it takes a function as its value instead of a string like the value attribute does. That also explains why you can "only use one of them" - calling window.onload reassigns the value of the onload attribute for the body tag.
Also, like others here are saying, usually it is cleaner to keep style and javascript separated from the content of the page, which is why most people advise to use window.onload or like jQuery's ready function.
Comments
They both work the same. However, note that if both are defined, only one of them will be invoked. I generally avoid using either of them directly. Instead, you can attach an event handler to the load event. This way you can incorporate more easily other JS packages which might also need to attach a callback to the onload event.
Any JS framework will have cross-browser methods for event handlers.
Comments
It is a accepted standard to have content, layout and behavior separate. So window.onload() will be more suitable to use than <body onload=""> though both do the same work.
Comments
Sorry for reincarnation of this thread again after another 3 years of sleeping, but perhaps I have finally found the indisputable benefit of window.onload=fn1; over <body onload="fn1()">. It concerns the JS modules or ES modules: when your onload handler resides in "classical" JS file (i.e. referred without <script type="module" ... >, either way is possible; when your onload handler resides in "module" JS file (i.e. referred with <script type="module" ... >, the <body onload="fn1()"> will fail with "fn1() is not defined" error. The reason perhaps is that the ES modules are not loaded before HTML is parsed ... but it is just my guess. Anyhow, window.onload=fn1; works perfectly with modules ...