W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2011

[whatwg] script element onerror event

From: Mike Wilson <mikewse@hotmail.com>
Date: Sun, 29 May 2011 14:42:55 +0200
Message-ID: <SNT129-DS2024AB71D0F254D2497424A4780@phx.gbl>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:33 UTC