davidflanagan.com > January 2006

More on the defer attribute

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!

When I first queried Dave about this, he responded like this:

The specification doesn't impose an ordering on the execution of script elements with the defer attribute set, so it would be unadvisable to rely on the ordering in a particular browser.

Yuck. This means that using the defer attribute opens up a big implementation dependecy. So I wrote back to press my point:

I think I disagree. The spec does say: "All SCRIPT elements are evaluated in order as the document is loaded." And the description of the defer attribute doesn't explicitly state that setting the defer attribute releases the user agent from the obligation to execute scripts in the order in which they appear.

I followed with a request that the spec be clarified:

Anyway, I suppose I'd suggest that this matter be clarified the next time an update is released. Since IE is apparently the only UA that honors the defer hint, I suppose the spec should probably be clarified in their favor, and should explicitly state that scripts with the defer attribute may be executed out-of-order

Dave says he's passed my request on. We'll see what comes of it. In the meantime, I guess I've got to give Microsoft's implementation the benefit of the doubt.

I used to say that any script that does not use document.write() could be deferred. I now understand that this is not the case, at least with the IE implementation. If you set the defer attribute on a script, you must be sure that the script has no interaction with any other scripts on your page, since you cannot know what order they will be executed in. (I suppose that if you defer a script and place it after all other scripts, then your script can safely use properties defined by the non-deferred scripts before it.) Well-written unobtrusive JavaScript code is often written in the form of modules that do not depend on what comes before or after, and these modules would then be candidates for the defer attribute.

May deferred scripts be executed out-of-order?

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

When are document elements available to scripts?

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.