January 2006 Archives

I've corresponded with Dave Raggett, editor of the HTML specification, about the defer attribute of the <script> tag. As I mentioned previously, I don't believe that the spec, as it stands, allows deferred scripts to be executed out of order, only deferred until another non-deferred script is encountered. Although Microsoft is the only vendor to implement this attribute, my reading of the spec is that they got it wrong.

Warning: this post is about minor details in the HTML spec. You probably should stop reading now!

The HTML specification defines a defer attribute for <script> tags. It is a hint to the browser that the script does not include calls to document.write() that produce output. Browsers are free, therefore to continue parsing and rendering the document while waiting for the script to load.

My understanding of this attribute has always been that scripts may only be deferred until the next non-deferred script is encountered. That is if the defer attribute is present, a script may be deferred, but it must still be executed in the order in which it appears.

This is not Microsoft's understanding, however. In IE, a deferred script runs out-of-order. Consider the following code:

<script>alert('first script');</script>
<script defer src="deferred.js"></script>
<script>alert('third script');</script>

IE only defers scripts that are loaded from external files, so the second line uses the src attribute to include the deferred.js file. This file simply contains another alert() call. When run in IE, we see that the first script is executed, then the third script is executed, and then the second script is executed.

My impulse is to bash Microsoft for getting this wrong, of course. The HTML spec does explicitly say "All SCRIPT elements are evaluated in order as the document is loaded.". I cannot be 100% certain that Microsoft is wrong however, because the spec does not mention execution order when describing the defer attribute:

defer [CI]

When set, this boolean attribute provides a hint to the user agent that the script is not going to generate any document content (e.g., no "document.write" in javascript) and thus, the user agent can continue parsing and rendering.

Microsoft deserves credit, I suppose, for actually having implemented the defer attribute; no other browsers appear to utilize the hint. I think they got the implementation wrong, though. In the absence of other implementations, however, it doesn't matter so much whether Microsoft follows the spec or not: we can just treat deferred scripts as an IE-only feature.

If you've got a different interpretation of the HTML spec, or know of other browsers that honor the defer attribute, let's hear about it in the comments

As far as I can tell, the DOM and HTML specifications are silient on the issue of when DOM elements become available to scripts embedded within the document. That is, if you have an element <div id="foo">, when can you call getElementById('foo') and be sure that you'll get a valid result?

To be safe, we typically wait for the onload() event. (Although the specifications don't explicitly guarantee that, either.) It appears to be common practice for browser vendors to make the DOM available while it is being parsed. That is, any script in the body of a document can access any elements that appear before it in the document.

Can anyone with more knowledge of the specifications, or with more experience writing production code comment on this issue?

This is, of course, related to the "onload problem" which Dean Edwards purports to have solved. In the comments to that post, Dean asserts that placing scripts at the very end of the body does not guarantee that those scripts will have access to the whole document. Dean's experience carries a lot of weight, but he does actually have code that demonstrates that this technique is unreliable.)

Comments are open.