I have a javascript function that manipulates the DOM when it is called (adds CSS classes, etc). This is invoked when the user changes some values in a form. When the document is first loading, I want to invoke this function to prepare the initial state (which is simpler in this case than setting up the DOM from the server side to the correct initial state).
Is it better to use window.onload to do this functionality or have a script block after the DOM elements I need to modify? For either case, why is it better?
For example:
function updateDOM(id) {
// updates the id element based on form state
}
should I invoke it via:
window.onload = function() { updateDOM("myElement"); };
or:
<div id="myElement">...</div>
<script language="javascript">
updateDOM("myElement");
</script>
The former seems to be the standard way to do it, but the latter seems to be just as good, perhaps better since it will update the element as soon as the script is hit, and as long as it is placed after the element, I don't see a problem with it.
Any thoughts? Is one version really better than the other?
The onload event is considered the proper way to do it, but if you don't mind using a javascript library, jQuery's $(document).ready() is even better.
$(document).ready(function(){
// manipulate the DOM all you want here
});
The advantages are:
Call $(document).ready() as many times as you want to register additional code to run - you can only set window.onload once.
$(document).ready() actions happen as soon as the DOM is complete - window.onload has to wait for images and such.
I hope I'm not becoming The Guy Who Suggests jQuery On Every JavaScript Question, but it really is great.
I've written lots of Javascript and window.onload is a terrible way to do it. It is brittle and waits until every asset of the page has loaded. So if one image takes forever or a resource doesn't timeout until 30 seconds, your code will not run before the user can see/manipulate the page.
Also, if another piece of Javascript decides to use window.onload = function() {}, your code will be blown away.
The proper way to run your code when the page is ready is wait for the element you need to change is ready/available. Many JS libraries have this as built-in functionality.
Check out:
http://docs.jquery.com/Events/ready#fn
http://developer.yahoo.com/yui/event/#onavailable
Definitely use onload. Keep your scripts separate from your page, or you'll go mad trying to disentangle them later.
Some JavaScript frameworks, such as mootools, give you access to a special event named "domready":
Contains the window Event 'domready', which will execute when the DOM has loaded. To ensure that DOM elements exist when the code attempting to access them is executed, they should be placed within the 'domready' event.
window.addEvent('domready', function() {
alert("The DOM is ready.");
});
window.onload on IE waits for the binary information to load also. It isn't a strict definition of "when the DOM is loaded". So there can be significant lag between when the page is perceived to be loaded and when your script gets fired. Because of this I would recommend looking into one of the plentiful JS frameworks (prototype/jQuery) to handle the heavy lifting for you.
#The Geek
I'm pretty sure that window.onload will be called again when a user hits the back button in IE, but doesn't get called again in Firefox. (Unless they changed it recently).
In Firefox, onload is called when the DOM has finished loading regardless of how you navigated to a page.
While I agree with the others about using window.onload if possible for clean code, I'm pretty sure that window.onload will be called again when a user hits the back button in IE, but doesn't get called again in Firefox. (Unless they changed it recently).
Edit: I could have that backwards.
In some cases, it's necessary to use inline script when you want your script to be evaluated when the user hits the back button from another page, back to your page.
Any corrections or additions to this answer are welcome... I'm not a javascript expert.
My take is the former becauase you can only have 1 window.onload function, while inline script blocks you have an n number.
onLoad because it is far easier to tell what code runs when the page loads up than having to read down through scads of html looking for script tags that might execute.
Related
The $(document).ready() function is not very good if the page fails to load completely, or if it's loading very slowly.
How could I modify the element as soon as it has been created? Some delay is fine, as long as it's not multiple seconds.
I am using Greasemonkey also, if that matters. But I would be interested in a solution that works outside of Greasemonkey too.
I wouldn't want to break the performance on the webpage either.
Edit: I do not own the website I am modifying. Therefore I cannot put any code there manually.
I tried window.onload = function(){} instead of $(document).ready(function(){}) but i noticed the jquery version was twice as fast.
Looks like people did not understand question before they downvoted.
I misunderstood your problem, so am rewriting my answer completely.
If $(document).ready() is too slow for you, then onload will definitely be too slow for you. Without a snippet of code, I can't give you something specific, but this should work for you:
var checkIfExists = setInterval(function() {
var exists = document.getElementById("foo");
if (exists) {
clearInterval(checkIfExists);
doStuff(exists);
}
}, 25);
function doStuff(element) {
element.innerHTML = "bar";
}
Make sure not to put this inside of any onload or ondomready / $(document).ready() event handlers.
Once this script loads, it will check if an element with the id of foo exists every 25 milliseconds. Once it can successfully find foo, it stops searching and runs function doStuff. Now, I don't know if what you want to modify actually has an id or not, so you will have to figure out exactly how to search for it.
I'm sure you know this, but I wanted to mention that the number of times the interval runs is heavily dependent upon where the script is loaded in the html document. For example, if it is at the bottom of the document it may only run once. If it is in the header, it will run just until foo is loaded.
Here is a working example with JSFiddle.
I have a question on jQuery $(document).ready
Let's say we have a HTML page which includes 2 JavaScript files
<script language="javascript" src="script1.js" ></script>
<script language="javascript" src="script2.js" ></script>
Now let's say in both these script files, we have $(document) as follows
Inside script1.js:
$(document).ready(function(){
globalVar = 1;
})
Inside script2.js:
$(document).ready(function(){
globalVar = 2;
})
Now my Questions are:
Will both these ready event function get fired ?
If yes, what will the order in which they get fired, since the
document will be ready at the same
time for both of them?
Is this approach recommended OR we should ideally have only 1
$(document).ready ?
Is the order of execution same across all the browsers (IE,FF,etc)?
Thank you.
Will both these ready event function get fired ?
Yes, they will both get fired.
what will the order in which they get fired, since the document will be ready at the same time for both of them?
In the way they appear (top to bottom), because the ready event will be fired once, and all the event listeners will get notified one after another.
Is this approach recommended OR we should ideally have only 1 $(document).ready ?
It is OK to do it like that. If you can have them in the same block code it would be easier to manage, but that's all there is to it. Update: Apparently I forgot to mention, you will increase the size of your JavaScript code if you do this in multiple files.
Is the order of execution same across all the browsers (IE,FF,etc)?
Yes, because jQuery takes the cross-browser normalization at hand.
See here: jQuery - is it bad to have multiple $(document).ready(function() {}); and here: Tutorials:Multiple $(document).ready()
Yes
Order of attach. jQuery internally maintains a readyList with Deferred objects.
It's partially a matter of taste. Having one ready handler will give you a nice overview of all that is happening, while multiple (i.e., one per included file) will make your code much more modular (i.e., you can include or remove a .js file and be sure that it provides and binds its own ready handler).
Yes - order of attach.
You can count on both handlers being executed in order of their script inclusion and globalVar being 2 after the second script reference, in any current browser.
If you want full control I strongly recommend only one $(document).ready();
If you load partial portions of HTML through ajax and the ajax response includes a $(document).ready();-script and you want to fire $(document).ready(); from script1.js, script2.js and so on in the ajax callback.. You have to duplicate PLENTY of code....
Good Luck!
/ $(window).ready(); ;)
Both will get fired
The value of the variable will be 2 once all the dust has settled.
The main thing which isn't recommended is using 2 different JS files, as Google PageSpeed, and Yahoo YSlow recommends, it's best to have all your Javascript codes in the same file.
as far as same event handlers, well, in all honesty, I see no reason why to do that, and it'll only make your code readability lousier.
I have no answer for that.
I want to call some JS after the page-load, this may involve a delay and as such I want the page loaded first so content is shown... but it seems that the code in onLoad handler is called before the rendering is complete. Is there a better event I can use, which is triggered when the page is 'finished'?
To clarify, I want to run some JS after the page is rendered on-screen, so a 'post-everything event' really.
There are several points of interest along the time sequence. This generic sequence is a good overview, even though different browsers and versions implement the details a little differently. (This assumes you're using raw Javascript and need to minimize cross-browser issues; with it's comprehensive internal handling of cross-browser issues JQuery is a little different):
T0] page-begun-- The browser has started working on the page, but otherwise the environment is in flux. Your JS operations may occur in the wrong context, and simply be flushed away when the right context stabilizes. You probably don't want to try to execute any JS at all.
T1] "onLoad" event-- [however you get events: addEventListener("Load"..., window.onload=..., etc.] All parts of the page have been identified and downloaded from the server and are in the local system's memory. In order for all parts to be identified, some parsing has already occurred. (Note that "load" is a cognate of "download", not "parse" nor "render".)
You now have the right environment and can begin to execute JS code without fear of losing anything. HOWEVER, operations that try to read or manipulate the HTML [getElementById(..., appendChild(..., etc.] may fail in strange ways, or may appear to work but then disappear, or may do something different than you expected.
T2] DOM-almost-ready-- This hack is very simple and fully cross browser. Just put your JS <script>...</script> at the very end of your HTML, just before the </body> tag. Most things will work right, although attempts to append to or modify the DOM at the very end of the <body> may produce surprising results. This isn't fully correct, but it works 99% of the time. Given its simplicity and the very high probability of correct operation, this may be the way to go (at least if you don't use JQuery).
T3] DOM-ready-- [however you get events: addEventListener("DOMContentLoaded"..., window.ondomcontentloaded=..., etc.] At this point the HTML has been completely parsed and JS is 100% available, including all functions that read or manipulate the HTML [getElementById(..., appendChild(..., etc.].
T4] Render-done-- The browser is finished displaying the content on the screen. There is NOT any such event or any reasonable cross-browser version-agnostic way to detect this situation. That's just as well, as you probably don't really want this anyway. If the browser has already displayed the page on the screen and then you manipulate the DOM, you'll get a "flash", where both the before and the after are visible on the screen at least briefly. What you probably really want is the point where you can execute arbitrary JS code; that's the previous (T3] DOM-ready) point in time.
Either attach a callback to window.onload
window.onload = function(){
// your code here
};
this will fire when all resources are loaded (which might be not what you want).
Or put all of your code at the bottom the page (before the closing body tag). The code will be run when the HTML is parsed.
FWIW, here is the jQuery code. You see, the use custom event handlers for IE and the other browsers, but use window.onload as fallback:
// Mozilla, Opera and webkit nightlies currently support this event
if ( document.addEventListener ) {
// Use the handy event callback
document.addEventListener( "DOMContentLoaded", DOMContentLoaded, false );
// A fallback to window.onload, that will always work
window.addEventListener( "load", jQuery.ready, false );
// If IE event model is used
} else if ( document.attachEvent ) {
// ensure firing before onload,
// maybe late but safe also for iframes
document.attachEvent("onreadystatechange", DOMContentLoaded);
// A fallback to window.onload, that will always work
window.attachEvent( "onload", jQuery.ready );
// If IE and not a frame
// continually check to see if the document is ready
var toplevel = false;
try {
toplevel = window.frameElement == null;
} catch(e) {}
if ( document.documentElement.doScroll && toplevel ) {
doScrollCheck();
}
}
As with a lot of JavaScript this will depend on which browser you are using.
As #Avitus' answer, have you looked at the execution point of JQuery's document ready event? This has been generalised across all browsers.
If you plan on using a javascript library (like jQuery) I would rather go with the $(document).ready() statement which is called once the DOM is ready to be manipulated.
The other option I see would be to include your function call at the end of your HTML page so that all the HTML content would be loaded so you can afterward execute your code safely
"The onload event waits for all binary content to download before firing. No kitty-tickilng until then."
As this post says, it is called after all binary content is downloaded, you need to listen for a ready event either using jQuery's ready, or your own function. This project looks interesting.
There are many cross browser implementations so use either jQuery or that project I linked to.
I have written my own function for my library, it uses internal methods so will not work on its own but might give you a feel for what you have to do. You can find that function here.
I have a page where I import most of my js in the <head> section.
The main page, however, has some inline JavaScript.
In one of my scripts imported in the <head>, I have $(document).ready... which uses some JS variables defined inline on the page.
As far as I can see, this works as I would expect -- $(document).ready doesn't run into any errors using the JS vars defined inline.
However, I have gotten some reports from users that they see " is not defined" error in code inside my $(document).ready where I reference the variable defined inline on the page.
I suspect this is browser specific behavior, but I'm not sure. I didn't find this explicitly in documentation, so can someone confirm that it's OK to use variables defined inline on a page in $(document).ready in JS pulled in from the <head>?
Citing your source would make your answer more credible. :)
Under the hood: $(document).ready()
As you would expect from John Resig, jQuery’s method for determining when the DOM is ready uses an assortment of optimizations.
For example, if a browser supports the DOMContentLoaded event (as many non-IE browsers do), then it will fire on that event. However, IE can’t safely fire until the document’s readyState reaches “complete”, which is typically later.
If none of those optimizations are available, window.onload will trigger the event
Source: here
Why not place a "script" tag at the end of the "body" tag that starts your app.
By doing this you are sure everything is in place to start (cross browser and cross library).
<html>
...
<script>startApp('param');</script>
</body>
</html>
"startApp" being a function defined anywhere before, either inline or in the "head" tag.
$(document).ready() uses an assortment of different methods for different browsers. Not too many browsers agree on how to handle this event, so there are a number of ways of testing it. I'm pretty sure the jQuery implementation, at least the IE hack, depends on inserting a fragment and checking it for the doScroll("left") property that should only exist once the DOM is ready. It's an undocumented behavior that could change with newer versions of IE.
The purpose of $(document).ready() is to allow you to run your DOM-dependent JavaScript before the page is finished loading, since window.onload doesn't fire until the entire page has been loaded.
The varying implementations also have varying levels of reliability. It sounds like one of the browsers is firing the script before it finishes loading.
Keep in mind that the order in which inline JavaScript is fired is not necessarily before ready. It sounds to me like you should consolidate your inline scripts into your $(document).ready() callback. jQuery does its best, but it's not perfect.
Your inline JS may not be processed before the event fires, as different browsers will work differently. You can assume that your ready function will start as soon as it can, but it is not known exactly when it will start.
You shouldn't assume that the ready function will start quickly, so you may need to write your inline logic to wait until this function has ran.
In javascript, coding to assumptions of when things will happen is risky, just as assuming that the property or function you want to use exists is risky, so you need to code very defensively.
You may want to put the inline javascript into functions and have it called from the ready function, or at least flip some flag to let the inline code know that it is now safe to run.
This will delay you by a tiny bit, most likely, but it will lead to a better user experience, I expect.
I'm using window.onload to call my JavaScript code that has to be executed after the page is fully loaded. From what I read this is the recommended method to call such scripts.
However, it does not work for some Ajax sites, www.bing.com for instance - window.onload is called before the pages is fully rendered.
Any suggestions?
The short answer is that there's no general way to solve this problem (right now).
The definition of a "page" is pretty fungible when AJAX comes into play - it's pretty hard to tell the difference between AJAX that is intended to be part of the initial page load, and that which might not be. So, browsers are left on their own to determine when window.onload() should be fired, and it doesn't always end up where you want.
Luckily, most people don't need a general solution, but rather a specific one. If you care about bing.com, then you can probably look at how bing.com works and design your code to trigger when the site reaches a state that you find acceptable.
I've wrestled with this a couple of times, and my usual reason for needing some sort of onload event triggering is to be able to interact with the HTML DOM and have getElementById, getElementsByTagName, or various other DOM selectors, return something other than nothing.
Once again, I'm not sure of the exact problem you are trying to solve, but if you must use some sort of onload, and it's because of DOM traversal of some kind, you can cheat a bit with the following sort of code:
window.onload = pageChecker;
function pageChecker() {
// Onload has fired, but we don't trust it.
// Check to see if our deepest nested element can be found
var testElement = document.getElementById("importantElement");
if ( !testElement ) {
// Try again in a bit, adjust timeout to what your users
// can tolerate
setTimeout(pageChecker, 50);
}
else {
//
// ... the element exists, run important code below ...
//
}
}
You might be able to listen for changes and requests by globally listening for DOMSubtreeModified and readystatechange events, and use those events instead of the load event for whatever you are trying to do.
I'd recomend using jQuerys $(...).ready() method.
In addition to the answer from Rasmus Kaj and if you are using jQuery, I would direct you to take a look at Global Ajax Event Handlers.
jQuery.fn.ajaxComplete (http://api.jquery.com/ajaxcomplete/)
jQuery.fn.ajaxStop (http://api.jquery.com/ajaxstop/)
Note, that this has nothing to do with the native onload event.