jdalton (John-David Dalton)

I think I spotted a typo:
require by your project -> required by your project

did it return an empty array ?

*shows a precedent for throwing errors when the dom is expected to be fully parsed

We have had this discussion before.

HTC documentation shows a president for throwing errors when the dom is expected to be fully parsed

The innerHTML property of the custom element is available once the oncontentready event has fired. Therefore, an event handler should be attached to this event in a Literal Content component that retrieves the innerHTML property of the custom element. Otherwise, an error occurs, which indicates that the innerHTML property is not yet available.

C++ doc.aspx&usg=AFQjCNFTmplJTJmc6zc7Eevg3mieshYrIg) shows similar API throws an error

Returns S_OK if successful, or an error value otherwise.

Or the fact that it has worked for 11 years

I do agree that event delegation is one way around this and jQuery has helper methods for that as well.

Complimentary documentation suggests that methods/properties that require the dom to be fully parsed, doscroll is one of them, will throw an error. It has behaved this way since it was supported in IE5 or so. The long history and bits of documentation make it a pretty safe bet. We can play "what if" until the cows come home. With IE9 still supporting VBScript and other oldies I don't see this as an issue. Also the doscroll technique is always accompanied with various other fallbacks.

doscroll will not throw errors when its being called from a secondary document (as stated in the tech article linked to on Diego's page). For example if called within an iframe doscroll will not throw errors. That's why IEContentLoaded has a fallback to at least fire before the onload event fires (even if its immediately before). The document.body check is better than nothing but will produce a false positive if you use loading techniques that flush the output buffer early.

John,

You will allow this, oh my.

It seems Garrett at least tried to help and provided a line number to boot. He is absolutely correct about function declarations in blocks, for additional reading check out kangax's excellent post on named-function-expressions. There is nothing stopping the next version of a supported browser from throwing an error (who knows?). Why take the chance.

In fact, ECMA 5th edition states on page 86 section 12:

NOTE: Several widely used implementations of ECMAScript are known to support the use of FunctionDeclaration as a Statement. However there are significant and irreconcilable variations among the implementations in the semantics applied to such FunctionDeclarations. Because of these irreconcilable difference, the use of a FunctionDeclaration as a Statement results in code that is not reliably portable among implementations. It is recommended that ECMAScript implementations either disallow this usage of FunctionDeclaration or issue a warning when such a usage is encountered. Future editions of ECMAScript may define alternative portable means for declaring functions in a Statement context.

I don't think its cool to lash out at a dev for trying to help just because he drops the comp.lang.javascript tag (my interpretation). Garrett is a great dev, I have learned plenty from him. Who knows you might too.