指定がない限り、このセクションの中のキューイングされるすべてのタスクに対するタスク・ソースは、メディア要素イベント・タスク・ソースです。

すべてのメディア要素は、関連のエラー状態を持ちます。それは、要素が、リソース選択アルゴリズムが最後に呼び出されてから遭遇した最新のエラーを記録したものです。error 属性は、取得においては、この最新のエラーで生成された MediaError オブジェクトを返さなければいけません。エラーがなければ null を返さなければいけません。

MediaError オブジェクトの code 属性は、該当のエラーに相当するコードを返さなければいけません。それは、次のいずれかです：

メディア要素の src 属性がセットされたり変更されたら、ユーザーエージェントは、そのメディア要素のメディア要素ロード・アルゴリズムを呼び出さなければいけません。（src 属性を削除した場合、たとえ、source 要素が存在していたとしても、これは行われません。）

メディア要素の src IDL 属性は、同じ名前の対応するコンテンツ属性を反映しなければいけません。

currentSrc IDL 属性は、空文字列で初期化されます。その値は、下記に定義されているリソース選択アルゴリズムによって変更されます。

canPlayType(type) メソッドは、type がユーザーエージェントがレンダリングできないと判定できるタイプなら、空文字列を返さなければいけません。ユーザーエージェントが、そのタイプは、この audio や video 要素で使われるなら再生可能なメディア・リソースを表していると、確信できるなら、"probably" を返さなければいけません。そうでなければ "maybe" を返さなければいけません。実装においては、そのタイプをサポートしているのか否か確信が持てない限り、"maybe" を返すことが推奨されます。一般的に、そのタイプに codecs パラメータがない場合は、ユーザーエージェントは、決して "probably" を返すべきではありません。

メディア要素がネットワークと影響し合うとき、それらの現在のネットワーク・アクティビティは、networkState 属性によって表されます。取得においては、この属性は該当の要素の現在のネットワーク状態を返さなければいけません。それは、次の値のうちのいずれかでなければいけません：

リソース選択アルゴリズムで、networkState 属性の値がいつ変更されるのか、そして、どんなイベントを発出してこの状態に変更したことを表すのかについて、その正確な定義は後述します。

すべてのメディア要素は、自動再生フラグを持ち、このフラグは、true 状態で始まらなければいけません。また、load イベント遅延フラグも持ちますが、このフラグは false 状態で始まらなければいけません。load イベント遅延フラグが true の間は、該当の要素は、そのドキュメントの load イベントを遅延しなければいけません。

メディア要素の load() メソッドが呼び出されるとき、ユーザーエージェントは、メディア要素ロード・アルゴリズムを実行しなければいけません。

メディア要素ロード・アルゴリズム は次の手順から構成されます。

1. この要素の実行中のリソース選択アルゴリズムのインスタンスをすべて中止します。

2. タスク・キューのタスクの中にメディア要素のメディア要素イベント・タスク・ソースからのタスクがあれば、それらのタスクを削除します。

   基本的に、該当のメディア要素の保留イベントとコールバックは、そのメディア要素が新規のリソースをロードし始めるときに、破棄されます。

3. メディア要素の networkState が NETWORK_LOADING または NETWORK_IDLE にセットされているなら、該当のメディア要素で abort という名前のシンプルなイベントを発出するタスクをキューイングします。

4. メディア要素の networkState が NETWORK_EMPTY にセットされていないなら、次の副手順を実行します：

   1. 該当のメディア要素でフェッチ処理が進行中なら、ユーザーエージェントはそれを停止するべきです。

   2. networkState 属性を NETWORK_EMPTY にセットします。
   3. readyState が HAVE_NOTHING にセットされていないなら、それをその状態にセットします。
   4. paused 属性が false なら、true にセットします。
   5. seeking が true なら、それを false にセットします。
   6. 現在の再生位置を 0 にセットします。

   7. 該当のメディア要素で emptied という名前のシンプルなイベントを発出するタスクをキューイングします。

5. playbackRate 属性を、defaultPlaybackRate の値にセットします。

6. error 属性を null に、そして、自動再生フラグを true にセットします。

7. メディア要素のリソース選択アルゴリズムを呼び出します。

8. 該当要素ですでにメディア・リソースの再生が存在していたら、それらすべてを停止します。

メディア要素のリソース選択アルゴリズムは次の通りです。このアルゴリズムは常に同期して呼び出されます。しかし、このアルゴリズムの最初の手順のひとつは、残りの手順を非同期に実行し続けて戻ることになります。つまり、実行中のスクリプトと他のタスクを平行してバックグラウンドで実行します。さらに、このアルゴリズムは、イベント・ループのメカニズムと密接に相互作業します。とりわけ、それは同期セクションを持ちます（イベント・ループのアルゴリズムの一部として呼び出されます）。このようなセクションの手順は ⌛ でマーキングされています。

1. networkState を NETWORK_NO_SOURCE にセットします。

2. 非同期に安定状態を待ち受けて、このアルゴリズムを呼び出したタスクが継続できるようにします。同期セクションは、このアルゴリズムが同期セクションは終了したと言うまで、このアルゴリズムの残りの手順すべてから構成されます。（同期セクションの手順は ⌛ でマーキングされています。）

3. ⌛ メディア要素が src 属性を持つなら、mode を attribute とします。

   ⌛ そうでなければ、メディア要素が src 属性を持たないけれども、source 要素を子に持つなら、mode を children とし、candidate を、その子のうちツリー順で最初の source 要素とします。

   ⌛ そうでなければ、メディア要素が src 属性も、子に source 要素も持たないなら、networkState を NETWORK_EMPTY にセットし、これらの手順を中止します。同期セクションは終了です。

4. ⌛ メディア要素の load イベント遅延フラグを true （これは load イベントを遅延させます）にセットし、その networkState を NETWORK_LOADING にセットします。

5. ⌛ メディア要素で loadstart という名前のシンプルなイベントを発出するタスクをキューイングします。

6. mode が attribute なら、次の副手順を実行します：

   1. ⌛ absolute URL を、src 属性の値によって指定された URL を該当の src 属性が最後に変更されたときのメディア要素に対して解決した結果となる絶対 URL とします。

   2. ⌛ absolute URL の取得に成功したら、currentSrc 属性を absolute URL にセットします。

   3. 同期セクションを終了します。残りの手順は非同期に継続します。

   4. absolute URL の取得に成功したら、absolute URL を使ってリソース・フェッチ・アルゴリズムを実行します。そのアルゴリズムがこのアルゴリズムを中止することなしに返るなら、ロードは失敗です。

   5. この手順に到達したということは、メディア・リソースのロードに失敗したか、指定の URL を解決できなかったということになります。error 属性を、新規の MediaError オブジェクトにセットします。その code 属性は MEDIA_ERR_SRC_NOT_SUPPORTED にセットされます。

   6. 該当の要素の networkState 属性を NETWORK_NO_SOURCE 値にセットします。

   7. 該当のメディア要素で error という名前のシンプル名イベントを発出するタスクをキューイングします。

   8. 該当の要素の load イベント遅延フラグを false にセットします。これによって、load イベントの遅延を止めます。

   9. これらの手順を中止します。load() メソッドが呼び出されるか、その src 属性が変更されるまで、この要素は別のリソースをロードしようとしません。

   そうでなければ、source 要素が使われます。次の副手順を実行します：

   1. ⌛ Let pointer be a position defined by two adjacent nodes in the media element's child list, treating the start of the list (before the first child in the list, if any) and end of the list (after the last child in the list, if any) as nodes in their own right. One node is the node before pointer, and the other node is the node after pointer. Initially, let pointer be the position between the candidate node and the next node, if there are any, or the end of the list, if it is the last node.

      As nodes are inserted and removed into the media element, pointer must be updated as follows:

      If a new node is inserted between the two nodes that define pointer

      Let pointer be the point between the node before pointer and the new node. In other words, insertions at pointer go after pointer.

      If the node before pointer is removed

      Let pointer be the point between the node after pointer and the node before the node after pointer. In other words, pointer doesn't move relative to the remaining nodes.

      If the node after pointer is removed

      Let pointer be the point between the node before pointer and the node after the node before pointer. Just as with the previous case, pointer doesn't move relative to the remaining nodes.

      Other changes don't affect pointer.

   2. ⌛ Process candidate: If candidate does not have a src attribute, then end the synchronous section, and jump down to the failed step below.

   3. ⌛ Let absolute URL be the absolute URL that would have resulted from resolving the URL specified by candidate's src attribute's value relative to the candidate when the src attribute was last changed.

   4. ⌛ If absolute URL was not obtained successfully, then end the synchronous section, and jump down to the failed step below.

   5. ⌛ If candidate has a type attribute whose value, when parsed as a MIME type (including any codecs described by the codecs parameter), represents a type that the user agent knows it cannot render, then end the synchronous section, and jump down to the failed step below.

   6. ⌛ If candidate has a media attribute whose value does not match the environment of the default view, then end the synchronous section, and jump down to the failed step below.

   7. ⌛ Set the currentSrc attribute to absolute URL.

   8. End the synchronous section, continuing the remaining steps asynchronously.

   9. Run the resource fetch algorithm with absolute URL. If that algorithm returns without aborting this one, then the load failed.

   10. Failed: Queue a task to fire a simple event named error at the candidate element, in the context of the fetching process that was used to try to obtain candidate's corresponding media resource in the resource fetch algorithm.

   11. Asynchronously await a stable state. The synchronous section consists of all the remaining steps of this algorithm until the algorithm says the synchronous section has ended. (Steps in synchronous sections are marked with ⌛.)

   12. ⌛ Find next candidate: Let candidate be null.

   13. ⌛ Search loop: If the node after pointer is the end of the list, then jump to the waiting step below.

   14. ⌛ If the node after pointer is a source element, let candidate be that element.

   15. ⌛ Advance pointer so that the node before pointer is now the node that was after pointer, and the node after pointer is the node after the node that used to be after pointer, if any.

   16. ⌛ If candidate is null, jump back to the search loop step. Otherwise, jump back to the process candidate step.

   17. ⌛ Waiting: Set the element's networkState attribute to the NETWORK_NO_SOURCE value.

   18. ⌛ Set the element's delaying-the-load-event flag to false. This stops delaying the load event.

   19. End the synchronous section, continuing the remaining steps asynchronously.

   20. Wait until the node after pointer is a node other than the end of the list. (This step might wait forever.)

   21. Asynchronously await a stable state. The synchronous section consists of all the remaining steps of this algorithm until the algorithm says the synchronous section has ended. (Steps in synchronous sections are marked with ⌛.)

   22. ⌛ Set the element's delaying-the-load-event flag back to true (this delays the load event again, in case it hasn't been fired yet).

   23. ⌛ Set the networkState back to NETWORK_LOADING.

   24. ⌛ Jump back to the find next candidate step above.

The resource fetch algorithm for a media element and a given absolute URL is as follows:

1. Let the current media resource be the resource given by the absolute URL passed to this algorithm. This is now the element's media resource.

2. Begin to fetch the current media resource, from the media element's Document's origin.

   Every 350ms (±200ms) or for every byte received, whichever is least frequent, queue a task to fire a simple event named progress at the element.

   If at any point the user agent has received no data for more than about three seconds, then queue a task to fire a simple event named stalled at the element.

   User agents may allow users to selectively block or slow media data downloads. When a media element's download has been blocked altogether, the user agent must act as if it was stalled (as opposed to acting as if the connection was closed). The rate of the download may also be throttled automatically by the user agent, e.g. to balance the download with other connections sharing the same bandwidth.

   User agents may decide to not download more content at any time, e.g. after buffering five minutes of a one hour media resource, while waiting for the user to decide whether to play the resource or not, or while waiting for user input in an interactive resource. When a media element's download has been suspended, the user agent must set the networkState to NETWORK_IDLE and queue a task to fire a simple event named suspend at the element. If and when downloading of the resource resumes, the user agent must set the networkState to NETWORK_LOADING.

   The preload attribute provides a hint regarding how much buffering the author thinks is advisable, even in the absence of the autoplay attribute.

   When a user agent decides to completely stall a download, e.g. if it is waiting until the user starts playback before downloading any further content, the element's delaying-the-load-event flag must be set to false. This stops delaying the load event.

   The user agent may use whatever means necessary to fetch the resource (within the constraints put forward by this and other specifications); for example, reconnecting to the server in the face of network errors, using HTTP range retrieval requests, or switching to a streaming protocol. The user agent must consider a resource erroneous only if it has given up trying to fetch it.

   The networking task source tasks to process the data as it is being fetched must, when appropriate, include the relevant substeps from the following list:

   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

   If the media resource is found to have Content-Type metadata that, when parsed as a MIME type (including any codecs described by the codecs parameter), represents a type that the user agent knows it cannot render (even if the actual media data is in a supported format)

   If the media data can be fetched but is found by inspection to be in an unsupported format, or can otherwise not be rendered at all

   DNS errors, HTTP 4xx and 5xx errors (and equivalents in other protocols), and other fatal network errors that occur before the user agent has established whether the current media resource is usable, as well as the file using an unsupported container format, or using unsupported codecs for all the data, must cause the user agent to execute the following steps:

   1. The user agent should cancel the fetching process.

   2. Abort this subalgorithm, returning to the resource selection algorithm.

   Once enough of the media data has been fetched to determine the duration of the media resource, its dimensions, and other metadata

   This indicates that the resource is usable. The user agent must follow these substeps:

   1. Set the current playback position to the earliest possible position.

   2. Set the readyState attribute to HAVE_METADATA.

   3. For video elements, set the videoWidth and videoHeight attributes.

   4. Set the duration attribute to the duration of the resource.

      The user agent will queue a task to fire a simple event named durationchange at the element at this point.

   5. Queue a task to fire a simple event named loadedmetadata at the element.

      Before this task is run, as part of the event loop mechanism, the rendering will have been updated to resize the video element if appropriate.

   6. If either the media resource or the address of the current media resource indicate a particular start time, then seek to that time. Ignore any resulting exceptions (if the position is out of range, it is effectively ignored).

      For example, a fragment identifier could be used to indicate a start position.

   7. Once the readyState attribute reaches HAVE_CURRENT_DATA, after the loadeddata event has been fired, set the element's delaying-the-load-event flag to false. This stops delaying the load event.

      A user agent that is attempting to reduce network usage while still fetching the metadata for each media resource would also stop buffering at this point, causing the networkState attribute to switch to the NETWORK_IDLE value. This is also where a user agent would stop buffering when honoring the media element's preload's Metadata state.

   The user agent is required to determine the duration of the media resource and go through this step before playing.

   Once the entire media resource has been fetched (but potentially before any of it has been decoded)

   Queue a task to fire a simple event named progress at the media element.

   If the connection is interrupted, causing the user agent to give up trying to fetch the resource

   Fatal network errors that occur after the user agent has established whether the current media resource is usable must cause the user agent to execute the following steps:

   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.

   4. 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.

   5. Set the element's delaying-the-load-event flag to false. This stops delaying the load event.

   6. Abort the overall resource selection algorithm.

   If the media data is corrupted

   Fatal errors in decoding the media data that occur after the user agent has established whether the current media resource is usable must cause the user agent to execute the following steps:

   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_DECODE.

   3. Queue a task to fire a simple event named error at the media element.

   4. 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.

   5. Set the element's delaying-the-load-event flag to false. This stops delaying the load event.

   6. Abort the overall resource selection algorithm.

   If the media data fetching process is aborted by the user

   The fetching process is aborted by the user, e.g. because the user navigated the browsing context to another page, the user agent must execute the following steps. These steps are not followed if the load() method itself is invoked while these steps are running, as the steps above handle that particular kind of abort.

   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_ABORTED.

   3. Queue a task to fire a simple event named abort at the media element.

   4. If the media element's readyState attribute has a value equal to HAVE_NOTHING, 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. Otherwise, set the element's networkState attribute to the NETWORK_IDLE value.

   5. Set the element's delaying-the-load-event flag to false. This stops delaying the load event.

   6. Abort the overall resource selection algorithm.

   If the media data can be fetched but has non-fatal errors or uses, in part, codecs that are unsupported, preventing the user agent from rendering the content completely correctly but not preventing playback altogether

   The server returning data that is partially usable but cannot be optimally rendered must cause the user agent to render just the bits it can handle, and ignore the rest.

   When the networking task source has queued the last task as part of fetching the media resource (i.e. once the download has completed), if the fetching process completes without errors, including decoding the media data, and if all of the data is available to the user agent without network access, then, the user agent must move on to the next step. This might never happen, e.g. when streaming an infinite resource such as Web radio, or if the resource is longer than the user agent's ability to cache data.

   While the user agent might still need network access to obtain parts of the media resource, the user agent must remain on this step.

   For example, if the user agent has discarded the first half of a video, the user agent will remain at this step even once the playback has ended, because there is always the chance the user will seek back to the start. In fact, in this situation, once playback has ended, the user agent will end up dispatching a stalled event, as described earlier.

3. If the user agent ever reaches this step (which can only happen if the entire resource gets loaded and kept available): abort the overall resource selection algorithm.

preload 属性は、何がベストなユーザー体験につながるのか、ウェブ制作者の考えについて、ユーザーエージェントにヒントを与えることを想定されています。この属性は全く無視されるかもしれません。例えば、明示的なユーザー設定や、利用可能なネット接続の状態に基づくことになります。この属性は、autoplay 属性が存在していれば、無視されなければいけません。

preload IDL 属性は、同じ名前のコンテンツ属性を反映しなければいけません。

buffered 属性は、新規のスタティックな正規化 TimeRanges オブジェクトを返さなければいけません。このオブジェクトは、この属性が評価された時点でユーザーエージェントがバッファしたメディア・リソースがあれば、そのレンジを表します。ユーザーエージェントは、その利用可能なレンジを正確に決定しなければいけません。これが退屈な精査によってしか決定できないということを考慮に入れても、そうしなければいけません。

通常は、これは、ゼロ地点で固定された単一のレンジとなるでしょう。しかし、例えば、ユーザーエージェントがシークに応えるため HTTP レンジ・リクエストを使うなら、複数の範囲となることも考えられます。

ユーザーエージェントは、以前にバッファしたデータを破棄することができます。

ゆえに、ある時点で buffered 属性から返されたオブジェクトのレンジ内に含まれるタイム位置が、その後、同じ属性によって返されるオブジェクトのレンジに含まれない状態となることがあり得ます。

duration 属性は、メディア・リソースの長さを秒で返さなければいけません。利用可能なメディア・リソースがなければ、この属性は Not-a-Number (NaN) 値を返さなければいけません。メディア・リソースが終わりがないものと分かったら（ストリーミング・ラジオなど）、この属性は正の Infinity 値を返さなければいけません。

ユーザーエージェントは、メディア・データを再生する前に、そして、readyState を HAVE_METADATA 以上の値にセットする前に、メディア・リソースの尺を判定しなければいけません。たとえ、そうするために該当のリソースを何カ所もをシークする必要があったとしてもです。

メディア・リソースの長さが変わったとき（不明だったものが判明したり、当初判定した長さが変わったりした場合など）、ユーザーエージェントは、該当のメディア要素で durationchange という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

"終わりがない" ストリームが何らかの理由で終わってしまった場合、当初は正の Infinity だった尺が、該当のストリームの最後のフレームかサンプルの時間に変更されるでしょう。そして、durationchange イベントが発出されるでしょう。同様に、ユーザーエージェントが当初はメディア・リソースの尺を正確に判定せずに見積もっただけで、後で最新の情報に基づいて見積もりを改訂した場合も、その尺は変更され、durationchange イベントが発出されるでしょう。

メディア要素は現在再生位置を持ちます。これははじめは 0 でなければいけません。現在位置とは、時間のことです。

currentTime 属性は、取得時には、秒で表された現在再生位置を返さなければいけません。セット時には、ユーザーエージェントは、新たな値へシークしなければいけません（例外が発生する可能性があります）。

メディア・リソースがストリーミングなら、ユーザーエージェントは、そのバッファした範囲を超えて、そのリソースから所定の部分を取得できないかもしれません。同様に、0 で始まらないタイムラインを持つメディア・リソースがあります。巻き戻し限界位置とは、ストリーム、または、ユーザーエージェントが再び取得できるリソースのうち、最も前の位置のことです。

startTime 属性は、取得時には、巻き戻し限界位置を秒で返さなければいけません。

巻き戻し限界位置が変わった場合：現在再生位置が巻き戻し限界位置の前なら、ユーザーエージェントは巻き戻し限界位置へシークしなければいけません。そうでなければ、ユーザーエージェントが過去 15 ～ 250ミリ秒に該当の要素で timeupdate イベントを発出しておらず、まだそのイベントに対するイベント・ハンドラを実行していないのであれば、ユーザーエージェントは、該当の要素で timeupdate という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

上記の要件、および、クリップのメタデータが判明したときキックするリソース・フェッチ・アルゴリズムにおける要件により、現在再生位置は巻き戻し限界位置より決して小さくなることはありません。

ユーザーエージェントは、巻き戻し限界位置から開始して、あたかも、メディア・リソースのタイムラインが直線的に増えていくように、振る舞わなければいけません。たとえ、該当のメディア・データが、順番が狂ったりオーバーラップしたタイム・コードを持つことになったとしてもです。

例えば、2 つのクリップを連結した 1 つのビデオ・ファイルがあるとしましょう。そのビデオ・フォーマットが 2 つのクリップのもともとの時間を持っているのであれば、そのビデオ・データのタイムラインの指定を、00:15 ～ 00:29 と 00:05 ～ 00:38 のようにできるのかもしれません。しかし、ユーザーエージェントは、このような時間指定には対応しないでしょう。代わりに、ひとつのビデオとして、00:15 ～ 00:29 と 00:29 ～ 01:02 のような時間指定に対応するでしょう。

loop IDL 属性は、同じ名前のコンテンツ属性を反映しなければいけません。

メディア要素は、ready state を持ちます。これは、現在再生位置でレンダリングする準備がどの程度できているかを表すものです。これがとる値は次の通りです；特定の時間でのメディア要素の ready 状態は、その要素の状態を表す値のうち最も大きいものとなります：

networkState が NETWORK_EMPTY でないメディア要素の ready 状態が変わるとき、ユーザーエージェントは次の手順に従わなければいけません：

ready 状態が HAVE_NOTHING から HAVE_METADATA になった場合

loadedmetadata DOM イベントが load() アルゴリズムの一環で発出されます。

ready 状態が HAVE_METADATA から HAVE_CURRENT_DATA に、または、それより大きい値になった場合

load() アルゴリズムが最後に呼び出されてから、このメディア要素にこれが発生したのが初めてなら、ユーザーエージェントは、この要素で、loadeddata という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

ready 状態が HAVE_FUTURE_DATA または HAVE_ENOUGH_DATA となったら、下記の関連する手順も実行しなければいけません。

ready 状態が HAVE_FUTURE_DATA または、それより大きい値だったのが、HAVE_CURRENT_DATA または、それより小さい値になった場合

waiting DOM イベントを、現在の再生の状態に応じて、発出することができます。

ready 状態が HAVE_CURRENT_DATA または、それより小さい値だったのが、HAVE_FUTURE_DATA となった場合

ユーザーエージェントは、canplay という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

要素が潜在的に再生中なら、ユーザーエージェントは playingという名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

ready 状態が HAVE_ENOUGH_DATA となった場合

以前の ready 状態が HAVE_CURRENT_DATA または、その値より小さかった場合、ユーザーエージェントは canplay という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。そして、さらに要素が潜在的に再生中であれば、playing という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

自動再生フラグが true で、paused 属性が true で、そのメディア要素に autoplay 属性が指定されているなら、ユーザーエージェントは、paused 属性を false にセットし、play という名前のシンプルなイベントを発出するタスクをキューイングし、playing という名前のシンプルなイベントを発出するタスクをキューイングすることもできます。

ユーザーエージェントの自動再生は必須ではありません。そして、ユーザーエージェントは、この件についてはユーザー設定を尊重することが推奨されます。ウェブ制作者は、スクリプトを使って強制的にビデオを再生するのではなく、autoplay 属性を使ってください。そうすれば、ユーザーは、望むとおりのビヘイビアを優先できるようになります。

いずれの場合も、ユーザーエージェントは、最終的に canplaythrough という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

readyState IDL 属性は、取得においては、メディア要素の現在の ready 状態を定義している前述の値を返さなければいけません。

autoplay IDL 属性は、同じ名前のコンテンツ属性を反映しなければいけません。

paused 属性は、メディア要素が一時停止されているかどうかを表します。この属性の初期値は true でなければいけません。

paused 属性が false で、readyState 属性が HAVE_FUTURE_DATA か HAVE_ENOUGH_DATA のいずれかで、再生が終了しておらず、再生がエラーによって停止されておらず、ユーザー操作によって一時停止されていないとき、そのメディア要素は潜在的に再生中といいます。

readyState が HAVE_METADATA または、その値より大きく、そして、次のいずれか、つまり、現在再生位置がメディア・リソースの最後で、再生方向が前進方向で、メディア要素に loop 属性が指定されていない、もしくは、現在再生位置が巻き戻し限界位置で、再生方向が後進方向である、のいずれかであるとき、そのメディア要素は再生が終了したといいます。

ended 属性は、メディア要素が再生終了で再生方向が前進方向なら true を返し、そうでなければ false を返さなければいけません。

メディア要素の readyState 属性が HAVE_METADATA または、それより大きい値であり、ユーザーエージェントが、メディア・データの処理中に非致命的エラーに遭遇し、そのエラーによって、現在再生位置におけるコンテンツを再生することができないとき、その要素はエラーによって停止されたといいます。

メディア要素の paused 属性が false で、readyState 属性が HAVE_FUTURE_DATA または HAVE_ENOUGH_DATA で、ユーザーエージェントが、メディア・リソース内で、そのリソースのセクションの再生を続けることができない位置に到達したとき、その要素はユーザー操作によって一時停止されたといいます。

メディア要素では、再生終了とユーザー操作による一時停止が同時に起こることがあり得ます。

潜在的に再生中のメディア要素が、ユーザー操作による一時停止によって再生を停止するとき、ユーザーエージェントは、timeupdate という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

潜在的に再生中のメディア要素が、その readyState 属性が HAVE_FUTURE_DATA より小さい値に変化したために再生を停止するとき、その要素が再生終了となっていない、または、再生がエラーによって停止されていない、または、再生がユーザー操作によって一時停止されていない、または、シーク・アルゴリズムが呼び出されていない、のいずれかに該当するなら、ユーザーエージェントは、その要素で waiting という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

現在再生位置が、再生方向が前進方向の場合に、メディア・リソースの最後に達するとき、ユーザーエージェントは次の手順に従わなければいけません：

1. 該当のメディア要素に loop 属性が指定されていたら、メディア・リソースの巻き戻し限界位置にシークして、これらの手順を終了します。

2. 再生を停止します。

   ended 属性が true になります。

3. ユーザーエージェントは、該当の要素で timeupdate という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

4. ユーザーエージェントは、該当の要素で ended という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

再生方向が後進方向の場合に、現在再生位置がメディア・リソースの巻き戻し限界位置に達するとき、ユーザーエージェントは次の手順に従わなければいけません：

1. 再生を停止します。

2. ユーザーエージェントは、該当の要素で timeupdate という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

defaultPlaybackRate 属性は、どのスピードでメディア・リソースの再生することになるのかを、その固有のスピードを表す倍数として、与えます。取得においては、それにセットされた最新の値を返さなければいけません。まだセットされていなければ、1.0 となります。セット時においては、この属性は新しい値にセットされなければいけません。

playbackRate 属性は、どのスピードでメディア・リソースを再生しているのかを、その固有のスピードを表す倍数として、与えます。もし、これが defaultPlaybackRate と同じでないなら、そのとき、ユーザーは、早送りかスロー・モーション再生といった機能を使っていることになります。この属性は変更可能です。取得時においては、それにセットされた最新の値を返さなければいけません。まだセットされていなければ、1.0 となります。セット時においては、この属性は新しい値にセットされなければいけません。そして、再生スピードを変えなければいけません（該当の要素が潜在的に再生中の場合）。

playbackRate が正の値かゼロなら、再生方向は前進方向となります。そうでなければ、それは後進方向となります。

ユーザーエージェントの "再生" 機能は、playbackRate 属性を、play() メソッドの手順を呼び出す前の defaultPlaybackRate 属性の値にセットしなければいけません。早送りや巻き戻しといった機能は、playbackRate 属性の変更だけによって実装されなければいけません。

defaultPlaybackRate や playbackRate 属性の値が変わるとき（スクリプトからセットされたか、または、例えばユーザー・コントロールの応答などの理由でユーザーの操作によってユーザーエージェントが直接に変更した、のいずれか）、ユーザーエージェントは、そのメディア要素で ratechange という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

played 属性は、新規のスタティックな正規化 TimeRanges オブジェクトを返さなければいけません。このオブジェクトは、この属性が評価された時点で、ユーザーエージェントがすでにレンダリングしたメディア・リソースがあれば、そのレンジを表します。

メディア要素で play() メソッド呼び出されるとき、ユーザーエージェントは次の手順を実行しなければいけません。

1. メディア要素の networkState 属性の値が NETWORK_EMPTY なら、そのメディア要素のリソース選択アルゴリズムを呼び出します。

2. 再生が終了し、再生方向が前進方向なら、そのメディア・リソースの巻き戻し限界位置にシークします。

   これは、ユーザーエージェントに、そのメディア要素で timeupdate という名前のシンプルなイベントを発出するタスクをキューイングさせることになります。

3. メディア要素の paused 属性が true なら、次の副手順を実行します：

   1. paused の値を false に変更します。

   2. 該当の要素で play という名前のシンプルなイベントを発出するタスクをキューイングします。

   3. 該当のメディア要素の readyState 属性が HAVE_NOTHING, HAVE_METADATA, HAVE_CURRENT_DATA のいずれかの値を持つなら、waiting という名前のシンプルなイベントを発出するタスクをキューイングします。

   4. そうでなければ、該当のメディア要素の readyState 属性は HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA のいずれかの値を持ちます。該当の要素で playing という名前のシンプルなイベントを発出するタスクをキューイングします。

4. 該当のメディア要素の自動再生フラグを false にセットします。

pause() メソッドが呼び出されるとき、ユーザーエージェントは次の手順を実行しなければいけません：

1. 該当のメディア要素の networkState 属性の値が NETWORK_EMPTY なら、そのメディア要素のリソース選択アルゴリズムを呼び出します。

2. 該当のメディア要素の自動再生フラグを false にセットします。

3. 該当のメディア要素の paused 属性が false なら、次の手順を実行します：

   1. paused の値を true に変更します。

   2. 該当の要素で timeupdate という名前のシンプルなイベントを発出するタスクをキューイングします。

   3. 該当の要素で pause という名前のシンプルなイベントを発出するタスクをキューイングします。

メディア要素が潜在的に再生中で、その Document が完全にアクティブな Document なら、その現在再生位置は、実経過時間の単位時間ずつ、メディア時間の playbackRate の単位で、単調に増加しなければいけません。

この仕様では、ユーザーエージェントが適切な再生レートをどうやって実現するのかについては定義していません。利用可能なプロトコルとメディアに依存して、ユーザーエージェントがサーバーに適切なレートでメディアデータを提供するようサーバーとネゴシエートして、（レートが変更されるときと、サーバーがストリーム再生レートを更新するときの間の期間を除いて）クライアントがフレームを落とさず動作できるようになるのが、現実的といえるでしょう。

playbackRate が負数（再生が後進方向）のとき、対応するあらゆるオーディオはミュートされなければいけません。playbackRate が、ユーザーエージェントがまともにオーディオを再生できないくらい遅いか早い場合も、対応するオーディオはミュートされなければいけません。playbackRate が 1.0 でなければ、ユーザーエージェントは、そのオーディオを忠実に再現する必要性に応じて、そのオーディオにピッチ調整を適用することができます。

playbackRate は 0.0 になることもあります。その時は、再生は一時中止されていないけれども（paused 属性は true になりませんし、pause イベントも発出されません）、現在再生位置は動きません。

潜在的に再生中ではあるものの、Documentの中にないメディア要素は、ビデオを一切再生してはいけません。しかし、オーディオ・コンポーネントは再生するべきです。 メディア要素は、自身へのリファレンスすべてが削除されたという理由で再生を停止してはいけません。自身へのリファレンスがまったくなくなった要素が、その要素に対して再生を続けられるオーディオがもうないところまで到達したら（例えば、その要素が一時中止されたり、クリップの終了まで到達したり、その playbackRate が 0.0 となった、といった理由）、その要素をガーベッジ・コレクションの対象とすることができます。

メディア要素の現在再生位置が変わるとき（例えば、再生やシークといった理由で）、ユーザーエージェントは次の手順を実行しなければいけません。現在再生位置が、その手順が実行されている間に変わってしまったなら、ユーザーエージェントは、その手順が完了するまで待たなければいけません。そして、即座にその手順から復帰しなければいけません。（ゆえに、これらの手順は、可能な限り、または、必要に応じて実行されます。もし、ひとつの反復に長い時間がかかったら、ユーザーエージェントは "追いつく" ために先を急ぐため、ある一定の範囲がスキップされることがあります。）

1. 通常再生中に現在再生位置の単調増加が通常になるところに至るほどに時間が達っしたなら、そして、ユーザーエージェントが過去 15 ～ 250 ミリ秒にその要素で timeupdate イベントを発出しておらず、そのイベントに対するイベント・ハンドラをまだ実行していないなら、ユーザーエージェントは、その要素で timeupdate という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。（明示的なシークといった他の場合では、関連のイベントが、現在再生位置の変更の全体のプロセスの一環として発出されます。）

   ゆえに、このイベントは、約 66Hz より早く、または、4Hz より遅く発出されることはありません。ユーザーエージェントは、システム・ロードと、イベント処理ごとの平均コストに基づいて、イベントの周期を変更することが推奨されます。そうすることで、ユーザーエージェントは、ビデオのデコード中でも、快適に処理できる頻度で、UI を更新することができるようになります。

メディア要素が Document から削除されるとき、そのメディア要素の networkState 属性の値が NETWORK_EMPTY 以外なら、ユーザーエージェントは、あたかも、pause() メソッドが呼び出されたかのように動作しなければいけません。

メディア要素の Document が完全にアクティブなドキュメントでなくなったら、その再生は、そのドキュメントが再度アクティブになるまで停止されるでしょう。

seeking 属性の値は当初は false でなければいけません。

ユーザーエージェントがメディア・リソースの特定の new playback position にシークすることを求められたら、それは、ユーザーエージェントは次の手順を実行しなければいけないことを意味します：

1. メディア要素の readyState が HAVE_NOTHING なら、ユーザーエージェントは INVALID_STATE_ERR 例外を発出しなければいけません（シークが、DOM メソッドや IDL 属性セットの呼び出しに応じたものなら）。そして、これらの手順を中止しなければいけません。

2. new playback position がメディア・リソースの最後を超えているようなら、それを、そのメディア・リソースの最後とします。

3. new playback position が巻き戻し限界位置に達していないなら、それをその位置にします。

4. （限りなく直近に変更された）new playback position が、seekable 属性に指定されたレンジになければ、ユーザーエージェントは、INDEX_SIZE_ERR を発出しなければいけません（そのシークが、DOM メソッドの呼び出しや IDL 属性セットに応えるものだった場合）。そして、これらの手順を中止しなければいけません。

5. 現在再生位置は、指定の new playback position にセットされなければいけません。

6. seeking IDL 属性は true にセットされなければいけません。

7. ユーザーエージェントは、その要素で timeupdate という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

8. メディア要素が、シーク開始直前に潜在的に再生中だったけれども、そのシークによって、その readyState 属性が HAVE_FUTURE_DATA より小さい値なってしまったら、ユーザーエージェントは、その要素で waiting という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

9. この手順に達するとき、ユーザーエージェントが、new playback position に対するメディア・データが利用可能かどうかをまだ確定していなかったなら、そして、もし確定できていたとしても、その位置を再生するのに十分なデータをまだデコードできていないのであれば、ユーザーエージェントは、その要素で seeking という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

10. シークが DOM メソッドの呼び出しや IDL 属性のセットに応えるものだったなら、スクリプトを継続します。これらの手順の残りは、非同期に実行されなければいけません。

11. ユーザーエージェントは、new playback position に対するメディア・データが利用可能かどうかを確定するまで、待たなければいけません。もし、確定できているなら、その位置を再生するのに十分なデータをデコードできるまで、待たなければいけません。

12. seeking IDL 属性は false にセットされなければいけません。

13. ユーザーエージェントは、その要素で seeked という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

seekable 属性は、この属性が評価された時点で、ユーザーエージェントがシークできるメディア・リソースのレンジがあれば、それを表す新規のスタティックな正規化 TimeRanges オブジェクトを返さなければいけません。

ユーザーエージェントがメディア・リソースのどこにでもシークできるなら、例えば、単純なムービー・ファイルで、ユーザーエージェントとサーバーが HTTP Range リクエストをサポートしているのであれば、この属性は、あるレンジを伴ったオブジェクトを返すでしょう。そのレンジとは、開始が最初のフレームの時間（通常はゼロ）で、終了は開始時間に duration 属性の値を足した時間（最終フレームの時間と同じはず）となります。

例えば、ユーザーエージェントが無限ストリームのスライディング・ウィンドウをバッファリングしているなら、連続的にレンジが変わるかもしれません。これは、例えば、生放送を映し出すデジタル・ビデオテープ・レコーダーで見受けられるビヘイビアです。

メディア・リソースは、内部的には、スクリプトから制御されるもの、または、インタラクティブなものとなります。ゆえに、メディア要素は、非直線的に再生することがあります。もしこれが発生すると、ユーザーエージェントは、非連続的な形で現在再生位置が変わるときは、常にシークのアルゴリズムが使われたかのように振る舞わなければいけません。

この属性が存在したら、または、メディア要素に対してスクリプティングが無効となっているなら、ユーザーエージェントは、ユーザーに対してユーザー・インタフェースを表示するべきです。このユーザー・インタフェースは、再生開始、一時停止、コンテンツの任意の位置にシーク（そのコンテンツが任意のシークをサポートするなら）、ボリューム変更、字幕や組み込みの手話トラックの表示・非表示の切替、オーディオ・トラックの切替やオーディオ解説のオンなどのように、ユーザーがより便利に使える機能を入れるべきです。（例えば、フル・スクリーンや独立したサイズ可変のウィンドウでの表示）。他のコントロールも利用できるようにすることができます。

この属性が存在しなかったとしても、ユーザーエージェントは、メディア・リソースの再生に作用するコントロールを提供することができます（例えば、再生、一時停止、シーク、ボリューム調整など）。しかし、これらの機能は、そのページの通常のレンダリングを妨げるべきではありません。このような機能は、例えば、メディア要素のコンテキスト・メニューに表示することができます。

可能なところでは（特に、開始、停止、一時停止、一時停止解除、音量のミュートや変更、そして、シークに対して）、ユーザーエージェントによって表示されたユーザー・インタフェース機能は、前述の DOM API の観点から実装されなければいけません。そうすることで、例えば、すべて同じイベントが発出されます。

controls IDL 属性は、同じ名前のコンテンツ属性を反映しなければいけません。

volume 属性は、メディア要素のあらゆるオーディオの割り当ての再生音量を返さなければいけません。その範囲は 0.0（無音） ～ 1.0（最大音量）です。最初は、そのボリュームは 1.0 でなければいけません。しかし、ユーザーエージェントは、サイトごとといった単位の中で、セッションをまたがって最後にセットされた音量を記憶することができます。そのため、このような値を使って、1.0 以外の値とすることもできます。セット時においては、新しい値が 0.0 ～ 1.0 の範囲にあれば、この属性は、その新しい値にセットされなければいけません。そして、その再生音量は、この属性をセットしてからできる限りすぐに、対応した値に調整されなければいけません。0.0 は無音となり、1.0 は最大音量となり、値が増えるに従って音量が増大していきます。この範囲は線形である必要はありません。最大音量セッティングは、システムの許容最大音量より低くても構いません。例えば、ユーザーが最大音量をセットすることができます。新しい値が 0.0 ～ 1.0 の範囲になければ、セット時においては INDEX_SIZE_ERR 例外を発出しなければいけません。

muted 属性は、オーディオ・チャネルがミュートされてるなら true を返し、そうでなければ、false を返さなければいけません。しかし、ユーザーエージェントは、サイトごとといった単位の中で、セッションをまたがって最後にセットされた値を記憶することができます。そのため、ミュート状態は、ミュート（true）として開始することができます。セット時においては、この属性は、新しい値にセットされなければいけません。新しい値が true なら、このメディア・リソースのオーディオ再生は、ミュートされなければいけません。false なら、オーディオ再生は有効とならなければいけません。

muted または volume 属性が変更されたら、ユーザーエージェントは、そのメディア要素で volumechangeという名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

length IDL 属性は、オブジェクトによって表されるレンジの数を返さなければいけません。

start(index) メソッドは、オブジェクトによって表される index 番目の開始位置を返さなければいけません。その値は、そのオブジェクトがカバーするタイムラインの開始から計測した秒数です。

end(index) メソッドは、オブジェクトによって表される index 番目の終了位置を返さなければいけません。その値は、そのオブジェクトがカバーするタイムラインの開始から計測した秒数です。

これらのメソッドが呼び出されるとき、引数 index が、そのオブジェクトによって表されるレンジの数に等しいかそれより大きいなら、これらのメソッドは INDEX_SIZE_ERR 例外を発出しなければいけません。

TimeRanges オブジェクトが正規化 TimeRanges オブジェクトであると言ったら、それが表すレンジは、次の基準に従わなければいけません：

• レンジの開始は、前のレンジすべての終了より大きくなければいけません。
• レンジの開始は、同じレンジの終了より前でなければいけません。

つまり、このようなオブジェクトのレンジはそれぞれ、順番に並べ替えられており、オーバーラップせず、空でもなく、接してもいません（隣接レンジは、ひとつの大きなレンジにまとめられます）。

メディア要素の buffered, seekable, played IDL 属性によって返されるオブジェクトによって使われるタイムラインは、その要素のメディア・リソースのタイムラインと同じでなければいけません。

4.8.9.13 セキュリティとプライバシーの考慮

Status: Last call for comments

video と audio 要素の主なセキュリティとプライバシー実装は、メディアを cross-origin で組み込む能力に由来しています。脅威の流れの方向が 2 つあります。敵対的なコンテンツから犠牲ページに向けての方向と、敵対的なページから犠牲コンテンツに向けての方向です。

犠牲ページが敵対的コンテンツを組み込む場合、そのコンテンツが、そのコンテンツを組み込む Document と相互作用しようとするスクリプトを含むかもしれない、という点が脅威となります。これを回避するため、ユーザーエージェントは、必ず、このコンテンツから組み込みページへアクセスが一切できないようにしなければいけません。DOM の概念を使うメディア・コンテンツの場合においては、その組み込まれるコンテンツは、あたかも、それ自身とは無関係なトップ・レベルのブラウジング・コンテキストの中に存在していたかのように、扱われなければいけません。

例えば、SVG アニメーションが video 要素に組み込まれたなら、ユーザーエージェントは、それから、外部のページの DOM にアクセスさせないでしょう。SVG リソースにあるスクリプトから見れば、その SVG ファイルは、親を持たない孤立したトップレベルのブラウジング・コンテキストの中に存在するかのように見えるでしょう。

敵対ページが犠牲コンテンツを組み込む場合は、その組み込んでいるページが、本来、そのコンテンツを組み込んでなければ、そのコンテンツの情報へアクセスできなかったにもかかわらず、そのコンテンツから情報を取得することができてしまう、という点が脅威となります。API は、いくつかの情報を見せてしまいます。メディアの存在、タイプ、時間、サイズ、ホストのパフォーマンス特性です。このような情報は潜在的に常に問題を抱えているものですが、実際には、同じ情報は、多かれ少なかれ、img 要素を使って取得できてしまいます。そのため、これは受け入れることになりました。

しかし、もし、ユーザーエージェントが、字幕や章題といったコンテンツの中のメタデータまで晒してしまう場合は、よりセンシティブな情報を取得できてしまうことになり、深刻です。このバージョンの API は、そういった情報を晒すことはありません。将来的には、この API は、組み込まれたコンテンツのサイトが、そのような情報を晒すことを許可したのかをチェックするために、CORS のようなメカニズムを再利用することが考えられます。[CORS]

攻撃者は、企業ネットワーク上のユーザーをだまして、その企業のイントラネット上にある事前に漏洩したロケーションからビデオをロードしようとするサイトへ誘い込むことができるでしょう。もし、そのビデオが、新製品の機密計画を含んでいたなら、字幕を読み出すことができるということは、守秘義務違反をもたらすことになるでしょう。