The spec has different code paths for "If the media data cannot be fetched at all, due to network errors, causing the user agent to give up trying to fetch the resource" and "If the connection is interrupted, causing the user agent to give up trying to fetch the resource".

In the case where readyState is still HAVE_NOTHING, is the spec asking UAs make a distinction between the case when some data (not headers?) has been received before the network error and the case when the network error occurs before any data (but potentially headers?) has been received? What is the reason for returning to the resource selection algorithm in one case but firing an error event and giving up in the other?

The reason I noticed this is because I've been checking readyState==HAVE_NOTHING to distinguish the first case -- "the media data cannot be fetched at all, due to network errors". This makes step 4 in  the second case dead code, it can never be reached. This is what it looks like:

if (readyState == HAVE_NOTHING) {
  // 1. The user agent should cancel the fetching process.
  // 2. Abort this subalgorithm, returning to the resource selection algorithm.
} else {
  // 1. The user agent should cancel the fetching process.
  // 2. Set the error attribute to a new MediaError object whose code attribute is set to MEDIA_ERR_NETWORK.
  // 3. Queue a task to fire a simple event named error at the media element.
  // Step 4:
  if (readyState == HAVE_NOTHING) {
    // THIS POINT CAN NEVER BE REACHED
    // set the element's networkState attribute to the NETWORK_EMPTY value and queue a task to fire a simple event named emptied at the element.
  } else {
    // set the element's networkState attribute to the NETWORK_IDLE value.
  }
  // etc ...
}

I could of course try to do what the spec says instead, but it doesn't seem intentional or like a very good idea. I'd suggest to always return to the resource selection algorithm if (readyState == HAVE_NOTHING) and keep only the "otherwise" branch at step 4.

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: Accepted
Change Description: see diff given below
Rationale: That was just a copy/paste error.

Checked in as WHATWG revision r6353.
Check-in comment: The way this was written was confusing as it seemed to conflict with the earlier network error case.
http://html5.org/tools/web-apps-tracker?from=6352&to=6353

mass-move component to LC1