4

Is it really necessary to wait for the "ready" (or "window.onload") events if your code only manipulates DOM elements that have already been parsed entirely?

The jQuery documentation for the "ready()" function demonstrates how you could wait to perform actions until the DOM is entirely ready but the example is for code (script tags) that are listed before the DOM elements in question. But it seems that code which appears after the necessary DOM elements in an HTML document has access to them since, presumably, the DOM is built as the browser parses the document.

For example, is it safe to assume that the following code is reliable in all situations or is it still necessary (or beneficial somehow) to use a ready/onload handler?

<body>
  <div id="foo"/>
  <script type="text/javascript">
    var foo = document.getElementById('foo');
    foo.innerHTML = 'The element #foo is loaded!';
  </script>
</body>

This SO question is very similar but I wanted to bump it to see if there is any more information.

Community
  • 1
  • 1
maerics
  • 133,300
  • 39
  • 246
  • 273

4 Answers4

6

If your JavaScript code is below the DOM elements and only modifies them exclusively, you don't need to wait for the DOM ready event.

However, keep in mind editing a DOM element which contains a script element (or more specifically, before the element's closing tag) used to cause big problems in IE6 (thanks T.J. Crowder) and IE7.

However, this requires inline scripts which can be a maintenance problem. It is preferred to have your JavaScript stored externally (and many speak of the benefits of including them before the closing body tag) for many benefits such as ease of maintenance and fine grained cache control.

Community
  • 1
  • 1
alex
  • 438,662
  • 188
  • 837
  • 957
  • 3
    +1 for your first and second paragraphs. @maerics, see [this thread](http://groups.google.com/group/closure-library-discuss/browse_thread/thread/1beecbb5d6afcb41) from the Google Closure library team about when you can manipulate elements (fairly good authority, the Closure library is used by millions of people every day). @alex: Your third paragraph doesn't make much sense. You talk about inline `script` elements blocking execution whilst being downloaded, but then talk about storing your JavaScript externally. – T.J. Crowder Apr 21 '11 at 05:25
  • 1
    @T.J. Thanks for vote. How should I improve my answer? Is it wrong or just worded ambiguously? – alex Apr 21 '11 at 05:27
  • 1
    @alex: Re third paragraph, I think it's *mostly* wording. Your update helps by removing the bit about "downloading." – T.J. Crowder Apr 21 '11 at 05:43
  • 1
    That referenced IE bug is **very** interesting. Note, the linked article and its resources imply (in some cases actually *say*) that this will only happen if the script code is directly within the `script` (not an external file). That is incorrect. It doesn't matter where the script code comes from (body of the element itself or an external file), the key thing is modifying the content of an unclosed element other than the immediate parent. This will trigger it with IE6, for instance, even though the `script` element refers to an external file: http://jsbin.com/elaga5/5 – T.J. Crowder Apr 21 '11 at 05:50
  • 1
    @T.J. You've never came across that bug? Consider yourself lucky :). I found it a bit in the wild in certain open source applications. – alex Apr 21 '11 at 05:52
  • @alex: I haven't, but I very rarely use `script` elements except in the `head` (small ones with inline code) or at the very end of `body` (referencing external files). Putting a `script` inside an element inside the body and then trying to modify the body...no, I don't do that. :-) – T.J. Crowder Apr 21 '11 at 05:54
1

in your case it is fine because the browser will render your code line by line and in your code id="foo" comes first so it will get that div....but suppose you wrote this script in head tag then the script will run first and it wont get the div with id="foo" because its not yet loaded..its better to write in document.ready method

Dharmesh
  • 989
  • 1
  • 11
  • 17
0

Yes, it's safe if you js code is after dom but usually it's not relly good idea to mix html and js.

x2.
  • 9,276
  • 5
  • 36
  • 62
0

Document is loaded in linear fashion so your code works correctly. Sometimes programmers do not use document ready for performance purpose when the javascript is not depends on the DOM below it. Here is some example.

katsuya
  • 1,184
  • 3
  • 15
  • 20