This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 14195 - Script and stylesheet elements need clearly defined rules for `load` and `error`
Summary: Script and stylesheet elements need clearly defined rules for `load` and `error`
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-17 21:06 UTC by Kyle Simpson
Modified: 2011-10-25 05:47 UTC (History)
11 users (show)

See Also:


Attachments

Description Kyle Simpson 2011-09-17 21:06:20 UTC
It is observed that the spec is not very crisp on the topic of how `error` events fire (in the absence of a `load` event) for both script elements and stylesheet elements -- specifically dynamically created elements. 

This ostensibly has led to the current state of such event support cross-browser -- which is very inconsistent/buggy. It is requested that clarification be made for both events for both element types, such that specific bugs can filed against each browser to bring them all into conformance.

Specifically, it seems like in the case of `load` and `error`, one of the two events should *always* fire for a script/stylesheet element. There should never be a case where an element falls in between and fires neither event.

Furthermore, we should be crisp/clear on what constitutes a successful "load" of such elements, so that the absence of `load` can predictably be fired as `error`.

I suggest:

* `load` should only fire if the element in question results in a 2xx or 3xx HTTP status code. `load` should fire even if the parsing/execution of the resource fails, but should always fire *after* that attempt, to maintain how existing script.onload works.

* `error` should fire in any other case, which would correspond to 4xx and 5xx HTTP error status codes.

* `error` is *not* to fire for parse/execution errors in either element type (script, stylesheet) -- it is purely for "failed to load" type errors.

-------------------

Discussion:

In various browsers, various HTTP status codes result in either the `error` event firing or not, and in some cases, neither a `load` nor a `error` fires. The behavior is even more confusing because it's not the same for scripts as it is for stylesheets.

There's even a case where a browser fires `error` in the event of a script error, which is confusingly incompatible with other browsers on the topic.
Comment 1 Ian 'Hixie' Hickson 2011-10-21 22:51:22 UTC
As far as I can tell, the spec is comprehensively crisp on this matter for <script>.

Could you elaborate on what you mean by "stylesheet elements"? <style>, <link>, or something else?

A test case demonstrating what is vague might be a good way to illustrate the problem here.
Comment 2 Ian 'Hixie' Hickson 2011-10-25 05:47:51 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: see comment 1