- From: Mike Wilson <mikewse@hotmail.com>
- Date: Sun, 29 May 2011 14:42:55 +0200
Hi John, This event is actually already speced, see #14 "fire a simple event named error at the element" in: http://www.whatwg.org/specs/web-apps/current-work/#prepare-a-script (and the onerror attribute is valid for all elements) Best regards Mike Wilson John J. Barton wrote: > To allow optional JavaScript download, some widely used JavaScript > libraries, such as jQuery and requireJS, use script elements added to > the document dynamically by JavaScript. (Of course this > feature is also > used by applications directly as well). For normal deployment this > approach works well in practice. At development time however, > or in the > presence of network or server problems, the approach gives poor error > recovery information. Fundamentally the problem is that the insertion > mechanism has no error return path. > > The script element does support one event, 'onload' which fires after > the script has finished loading. I suggest the addition of one new > event, 'onerror', which fires in every other case. For examples, a > network error (4XX, 5XX) or JavaScript parse error would > trigger onerror > but not onload. On the other hand, a runtime error for the > outer-function of the script element would trigger onload (I > guess), but > the developer can handle this with try/catch. > > Very long load times would still have poor error recovery > information, > but developers could implement UI to signal "loading..." once > they know > they will get some update event eventually. > > jjb >
Received on Sunday, 29 May 2011 05:42:55 UTC