On 5/29/2011 5:42 AM, Mike Wilson wrote:
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)
Thanks. I stopped before I got that far. Step 12.5:
"Ifeventis not anASCII case-insensitive
<http://www.whatwg.org/specs/web-apps/current-work/#ascii-case-insensitive>match
for either the string "|onload|" or the string "|onload()|", then the
user agent must abort these steps at this point. The script is not
executed."
Now I see I missed the *and* in the predicate for step 12, "If
the|script
<http://www.whatwg.org/specs/web-apps/current-work/#the-script-element>|element
has an|event
<http://www.whatwg.org/specs/web-apps/current-work/#attr-script-event>|attribute
and a|for
<http://www.whatwg.org/specs/web-apps/current-work/#attr-script-for>|attribute..."
(I've not seen a "for" attribute on a script element. Is there any
documentation on what it does?)
Step 14 is unclear or incomplete however:
" If the|src
<http://www.whatwg.org/specs/web-apps/current-work/#attr-script-src>|attribute's
value is the empty string or if it could not be resolved,..."
Does this mean the error handler will be called in the case of 4XX, 5XX,
and syntax errors?
jjb
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
