規定されていないことを除いて、このセクションとサブ・セクションでキューイングされるすべてのタスクに対するタスク・ソースは、メディア要素イベント・タスク・ソースとなります。

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

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

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

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

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

canPlayType(type) メソッドは、type がユーザーエージェントがレンダリングできないと認識するタイプ、または、"application/octet-stream" なら、空文字列を返さなければいけません。該当の 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. そのメディア要素で emptied という名前のシンプルなイベントを発出するタスクをキューイングします。

   2. そのメディア要素でフェッチ・プロセスが進行中なら、ユーザーエージェントはそれを停止するべきです。

   3. networkState 属性を NETWORK_EMPTY にセットします。

   4. そのメディア要素のメディア要素固有のテキスト・トラックを忘れます。

   5. readyState が HAVE_NOTHING にセットされないのであれば、その状態にセットします。

   6. paused 属性が false なら、true にセットします。

   7. seeking が true なら、false にセットします。

   8. 現在再生位置を 0 にセットします。

      これによって現在再生位置が変わるなら、そのメディア要素で timeupdate という名前のシンプルなイベントを発出するタスクをキューイングします。

   9. 初期再生位置を 0 にセットします。

   10. タイムライン・オフセットを Not-a-Number (NaN) にセットします。

   11. duration 属性を Not-a-Number (NaN) にアップデートします。

       ユーザーエージェントは、この特別な尺の変更に対しては、durationchange イベントを発出しないでしょう。

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

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

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

8. この要素ですでに再生しているメディア・リソースの再生は停止します。

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

1. Set the networkState to NETWORK_NO_SOURCE.

2. Asynchronously await a stable state, allowing the task that invoked this algorithm to continue. 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 ⌛.)

3. ⌛ If the media element has a src attribute, then let mode be attribute.

   ⌛ Otherwise, if the media element does not have a src attribute but has a source element child, then let mode be children and let candidate be the first such source element child in tree order.

   ⌛ Otherwise the media element has neither a src attribute nor a source element child: set the networkState to NETWORK_EMPTY, and abort these steps; the synchronous section ends.

4. ⌛ Set the media element's delaying-the-load-event flag to true (this delays the load event), and set its networkState to NETWORK_LOADING.

5. ⌛ Queue a task to fire a simple event named loadstart at the media element.

6. If mode is attribute, then run these substeps:

   1. ⌛ Process candidate: If the src attribute's value is the empty string, then end the synchronous section, and jump down to the failed step below.

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

   3. ⌛ If absolute URL was obtained successfully, set the currentSrc attribute to absolute URL.

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

   5. If absolute URL was obtained successfully, run the resource fetch algorithm with absolute URL. If that algorithm returns without aborting this one, then the load failed.

   6. Failed: Reaching this step indicates that the media resource failed to load or that the given URL could not be resolved. In one atomic operation, run the following steps:

      1. Set the error attribute to a new MediaError object whose code attribute is set to MEDIA_ERR_SRC_NOT_SUPPORTED.

      2. Forget the media element's media-resource-specific text tracks.

      3. Set the element's networkState attribute to the NETWORK_NO_SOURCE value.

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

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

   9. Abort these steps. Until the load() method is invoked or the src attribute is changed, the element won't attempt to load another resource.

   Otherwise, the source elements will be used; run these substeps:

   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, or if its src attribute's value is the empty string, 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, for types that define that 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, 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. ⌛ Forget the media element's media-resource-specific text tracks.

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

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

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

   16. ⌛ 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.

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

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

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

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

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

   22. 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 ⌛.)

   23. ⌛ 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).

   24. ⌛ Set the networkState back to NETWORK_LOADING.

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

メディア要素のリソース・フェッチ・アルゴリズムと、引き渡される絶対 URL は次の通りです：

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, with the force same-origin flag set.

   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.

   The stall timeout is a user-agent defined length of time, which should be about three seconds. When a media element that is actively attempting to obtain media data has failed to receive any data for a duration equal to the stall timeout, the user agent must 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, if the parameter is defined for that type), 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, and once the text tracks are ready

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

   1. Establish the media timeline for the purposes of the current playback position, the earliest possible position, and the initial playback position, based on the media data.

   2. Update the timeline offset to the date and time that corresponds to the zero time in the media timeline established in the previous step, if any. If no explicit time and date is given by the media resource, the timeline offset must be set to Not-a-Number (NaN).

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

   4. Update the duration attribute with the time of the last frame of the resource, if known, on the media timeline established above. If it is not known (e.g. a stream that is in principle infinite), update the duration attribute to the value positive Infinity.

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

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

   6. Set the readyState attribute to HAVE_METADATA.

      A loadedmetadata DOM event will be fired as part of setting the readyState attribute to a new value.

   7. Let jumped be false.

   8. If either the media resource or the address of the current media resource indicate a particular start time, then set the initial playback position to that time, seek to that time, and let jumped be true. Ignore any resulting exceptions (if the position is out of range, it is effectively ignored).

      For example, with media formats that support the Media Fragments URI fragment identifier syntax, the fragment identifier can be used to indicate a start position. [MEDIAFRAG]

   9. If either the media resource or the address of the current media resource indicate a particular set of audio or video tracks to enable, then the selected audio tracks must be enabled in the element's audioTracks object, and the first selected video track must be selected in the element's videoTracks object.

   10. If the media element has a current media controller, then: if jumped is true and the initial playback position, relative to the current media controller's timeline, is greater than the current media controller's media controller position, then seek the media controller to the media element's initial playback position, relative to the current media controller's timeline; otherwise, seek the media element to the media controller position, relative to the media element's timeline, discarding any resulting exceptions.

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

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

   If the media resource is found to declare a media-resource-specific text track that the user agent supports

   If the media resource's origin is the same origin as the media element's Document's origin, queue a task to run the steps to expose a media-resource-specific text track with the relevant data.

   Cross-origin files do not expose their subtitles in the DOM, for security reasons. However, user agents may still provide the user with access to such data in their user interface.

   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 属性は、最適なユーザー体験を実現するためにウェブ制作者はどう考えているのかについて、ユーザーエージェントにヒントを与えることを意図しています。この属性を完全に無視することもできます。例えば、ユーザー設定があれば、それを基準にしたり、ネットワーク接続状況を基準にすることができます。

preload IDL 属性は同じ名前のコンテンツ属性を反映しなければいけません。ただし、既知の値に限定されます。

buffered 属性は、新たな静的な 正規化 TimeRanges オブジェクト を返さなければいけません。これは、この属性が評価された時点で、ユーザーエージェントがすでにバッファしたメディア・リソースの範囲があれば、それを表します。ユーザーエージェントは、利用可能な範囲を正確に判定しなければいけません。たとえ、それが、メディア・ストリームのように、面倒な調査によってでしか判定できない場合だったとしてもです。

通常は、これは、ゼロ地点で固定された範囲ひとつだけになります。しかし、例えば、ユーザーエージェントが HTTP レンジ・リクエストを使ってシークする場合は、その範囲は複数になりえます。

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

ゆえに、ある時点で buffered 属性によって返されたオブジェクトの範囲内にある時間位置は、後の時間に同属性によって返されるオブジェクトの範囲（複数かもしれません）に含まれないということがあり得ます。

メディア・リソースには、メディア・タイムラインがあります。これは、メディア・リソースにおける位置に時間（単位は秒）を対応付けたものです。タイムラインの起点は、その最前の定義位置です。タイムラインの尺は、その最後の定義位置になります。

メディア・タイムラインの確立: メディア・リソースが、何とかして起点が負とならない明確なタイムラインを確定できるなら、メディア・タイムラインは、そのタイムラインとするべきです。（メディア・リソースがタイムラインを確定できるかどうかは、そのメディア・リソースのフォーマットに依存します。）メディア・リソースが明確な開始の時刻と加えて日付まで確定できるなら、その時刻と日付をメディア・タイムラインにおけるゼロ地点と見なすべきです。タイムライン・オフセットは時刻と日付を持ち、startOffsetTime 属性を使ってアクセスすることができます。

メディア・リソースが不連続なタイムラインを持つなら、ユーザーエージェントは、そのタイムラインを拡張して、そのリソースの開始からリソース全体に及ぶようにしなければいけません。そうすることで、そのメディア・リソースのメディア・タイムラインは、巻き戻し限界位置（後で定義します）から連続して増えていくことができるようになります。たとえ、下層のメディア・データの時間順がおかしかったり、時間コードがオーバーラップしていたとしてもです。

例えば、2 つのクリップをひとつのビデオ・ファイルに連結したけれども、そのビデオ・フォーマットから、その 2 つのクリップの起点時間を取り出せるなら、そのビデオ・データからタイムラインを取り出すことができるでしょう。それは、00:15..00:29 と 00:05..00:38 となるでしょう。しかし、ユーザーエージェントは、これらの時間を見せません。その代わり、00:15..00:29 と 00:29..01:02 という時間で、ひとつのビデオとして見せることになるでしょう。

明確なタイムラインが無くても、メディア・タイムラインのゼロ時間は、そのメディア・リソースの最初のフレームに合わせるべきです。静的なオーディオやビデオ・ファイルでは、これは通常は自明なことです。ストリーミング・リソースでは、サーバーから得た最初のフレームより前の位置にユーザーエージェントがシークできるのであれば、そのゼロ時間は、そのメディア・リソースの巻き戻し可能な範囲のうち最も前の時間に合わせるべきです。そうでなければ、サーバーから受信した最初のフレームに合わせるべきです（ユーザーエージェントがストリームを受信し始めた時点におけるメディア・リソースの位置です）。

他にもストリームの例があります。いくつかのフラグメントを連結してサーバーからブロードキャストする場合です。この場合、ユーザーエージェントは特定の時間をリクエストすることができませんが、事前に順番が決まっていれば、そのビデオ・データを配信することができます。ユーザーエージェントがこのストリームに接続して、タイムスタンプが 2010-03-20 23:15:00 UTC から 2010-03-21 00:05:00 UTC までと、2010-02-12 14:25:00 UTC から 2010-02-12 14:35:00 UTC までの範囲と定義されたフラグメントを受信したとすれば、これを、0 秒から始まり 3,600 秒（1時間）まで拡張したメディア・タイムラインとして見せることになるでしょう。ストリーミング・サーバーが 2 つ目のクリップの最後で切断すると仮定すれば、その duration 属性は 3,600 を返すことになります。startOffsetTime 属性は、2010-03-20 23:15:00 UTC に相当する時間を表す Date オブジェクトを返すことになります。しかし、別のユーザーエージェントが 5 分後に接続するとしたら、（恐らく）タイムスタンプが 2010-03-20 23:20:00 UTC から 2010-03-21 00:05:00 UTC までと、2010-02-12 14:25:00 UTC から 2010-02-12 14:35:00 UTC までの範囲となるフラグメントを受信することになります。そして、これを、0 秒から始まり 3,300 秒（55分）まで拡張したメディア・タイムラインとして見せることになります。この場合、startOffsetTime 属性は、2010-03-20 23:20:00 UTC に相当する時間を表す Date オブジェクトを返すことになります。

どんな場合でも、ユーザーエージェントは、確立したメディア・タイムラインを使って、巻き戻し限界位置（後で定義します）が必ず 0 以上となるようにしなければいけません。

メディア・タイムラインはクロックも結び付けられます。どのクロックを使うかは、ユーザーエージェント側の定義となり、メディア・リソース次第となりますが、ユーザーの実時間に近づけるべきです。

現在のメディア・コントローラを共有するすべてのメディア要素は、メディア・タイムラインに同じクロックを使います。

メディア要素には現在再生位置があります。これは、はじめ（つまり、メディア・データがない時点）は 0 秒でなければいけません。現在再生位置は、メディア・タイムライン上のひとつの時間です。

currentTime 属性は、取得時においては、現在再生位置を返さなければいけません。単位は秒です。セット時においては、もしメディア要素に現在のメディア・コントローラがあるなら、INVALID_STATE_ERR 例外を投げなければいけません。そうでなければ、ユーザーエージェントは新たな値（例外を発するかもしれませんが）へシークしなければいけません。

メディア要素には初期再生位置,があります。これは、はじめ（つまり、メディア・データがない時点）は 0 秒でなければいけません。初期再生位置は、メディア・リソースがロードされたときに更新されます。初期再生位置は、メディア・タイムライン上のひとつの時間です。

initialTime 属性は、取得時においては、初期再生位置を返さなければいけません。単位は秒です。

メディア・リソースがストリーミング・リソースなら、ユーザーエージェントは、バッファから削除した後では、そのリソースの特定の部分を取得することができなくなります。同様に、0 で始まらないメディア・タイムラインを持つメディア・リソースもあります。巻き戻し限界位置とは、ストリームやリソースのうち、ユーザーエージェントがもう一度取り出すことができる最も前の位置のことです。これも、メディア・タイムライン上のひとつの時間です。

巻き戻し限界位置は API で明確に見せるものではありません。これは、seekable 属性の TimeRanges オブジェクトがあれば、その最初の範囲の開始時間に一致します。そうでなければ、現在再生位置となります。

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

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

duration 属性は、メディア・タイムライン上のメディア・リソースの最後の時間を返さなければいけません。単位は秒です。利用可能なメディア・データがなければ、この属性は Not-a-Number (NaN) 値を返さなければいけません。メディア・リソースに範囲がない（ストリーミング・ラジオなど）と分かったら、この属性は正の Infinity 値を返さなければいけません。

ユーザーエージェントは、あらゆるメディア・データを再生する前、そして、readyState に HAVE_METADATA に等しいか大きい値をセットする前に、そのメディア・リソースの尺を決定しなければいけません。たとえ、そうするためにリソースの複数の部分をフェッチする必要があったとしてもです。

メディア・リソースの長さが既知の値（例えば、未知の値から既知の値へ、または、以前に確立した長さから別の値に）に変わるとき、ユーザーエージェントは、そのメディア要素で durationchange という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。（尺が新たなメディア・リソースのロードの一環でリセットされるときには、このイベントは発出されません。）

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

明確な時刻と日付をメディア・タイムラインのゼロ時間に対応付けするビデオ・ファイルもあります。これをタイムライン・オフセットと呼びます。タイムライン・オフセットは、最初に Not-a-Number (NaN) にセットされなければいけません。

startOffsetTime 属性は、現在のタイムライン・オフセットを表す Date オブジェクトを返さなければいけません。

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

メディア要素には準備状態があります。これは、現在再生位置でレンダリングする準備ができた度合いがどれくらいかを表します。その取り得る値は次の通りですが、特定の時間におけるメディア要素の準備状態は、その要素の状態を表している値のうちで最も大きい値になります：

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

1. 次のリストから最初に適用可能な副手順を適用します：

   準備状態が HAVE_NOTHING から HAVE_METADATA になる場合

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

   このタスクの実行前に、イベント・ループ・メカニズムの一環として、適切であれば、その video 要素をリサイズするためにレンダリングし直すでしょう。

   準備状態が HAVE_METADATA から HAVE_CURRENT_DATA 以上になる場合

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

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

   準備状態が HAVE_FUTURE_DATA 以上から HAVE_CURRENT_DATA 以下になる場合

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

   準備状態が HAVE_CURRENT_DATA 以下から HAVE_FUTURE_DATA になる場合

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

   この要素の paused 属性が false なら、ユーザーエージェントは playing という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

   準備状態が HAVE_ENOUGH_DATA になる場合

   準備状態が HAVE_CURRENT_DATA 以下だったなら、ユーザーエージェントは canplay という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。そして、その要素の paused 属性が false なら、playing という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

   自動再生フラグが true で、paused 属性が true で、そのメディア要素に autoplay 属性が指定されており、そのメディア要素の Document のブラウジング・コンテキストが、その Document が生成されたときに、サンドボックス化オートマチック・フィーチャー・ブラウジング・コンテキスト・フラグ がセットされていなかったのであれば、ユーザーエージェントは、paused 属性を false にセットし、play という名前のシンプルなイベントを発出するタスクをキューイングし、playing という名前のシンプルなイベントを発出するタスクをキューイングすることができます。

   ユーザーエージェントは autoplay をサポートする必要はありません。そして、ユーザーエージェントはユーザー設定を優先することが推奨されています。ウェブ制作者は、ビデオを強制的に再生させるのに、スクリプトを使うのではなく、autoplay 属性を使うことが推奨されます。そうすることで、ユーザーは希望通りに挙動を変えることができるようになります。

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

2. メディア要素に現在のメディア・コントローラがあるなら、そのメディア要素の現在のメディア・コントローラのコントローラ状態を報告します。

readyState IDL 属性は、取得時においては、前述のメディア要素の現在の準備状態の説明された通りの値を返さなければいけません。

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

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

readyState 属性が HAVE_NOTHING 状態か HAVE_METADATA 状態にある、または、その要素がユーザー操作待受停止されたなら、そのメディア要素はブロック化メディア要素であると言います。

paused 属性が false のとき、再生終了しておらず、再生はエラーによって停止されておらず、現在のメディア・コントローラがない、または、現在のメディア・コントローラはあるもののメディア・コントローラでブロックされていない、のいずれかで、かつ、ブロック化メディア要素でないとき、そのメディア要素は潜在的に再生中と言います。

メディア要素は、次の状態のとき、再生終了されたと言います：

• 該当の要素の readyState 属性が HAVE_METADATA、または、それ以上であり、かつ、

• 以下のいずれか:

  • 現在再生位置がメディア・リソースの最後であり、かつ、
  • 再生方向が前進であり、かつ、
  • 該当のメディア要素に loop 属性が指定されていない、または、該当のメディア要素に現在のメディア・コントローラがある、のいずれか。

  または:

  • 現在再生位置が巻き戻し限界位置であり、かつ、
  • 再生方向が後進である。.

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

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

paused 属性が false で、readyState 属性が HAVE_FUTURE_DATA または HAVE_ENOUGH_DATA のいずれかで、ユーザーエージェントが、メディア・リソースの中で、ユーザーがリソースを継続するかを選択しなければならない地点に到達したとき、そのメディア要素はユーザー操作待受停止したと言います。これが起こったときにメディア要素に現在のメディア・コントローラがあるなら、ユーザーエージェントは、そのメディア要素の現在のメディア・コントローラのコントローラ状態を報告しなければいけません。ユーザーが選択を行うとき、そのメディア要素に現在のメディア・コントローラがあり、再生の再開を許すのであれば、同様に、ユーザーエージェントはそのメディア要素の現在のメディア・コントローラのコントローラ状態を報告しなければいけません。

メディア要素で再生終了とユーザー操作待受停止の両方の状態が同時に起こることがあり得ます。

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

潜在的に再生中の要素が再生を停止した結果として、waiting DOM イベントが発出されることがあります。これは、その readyState 属性が HAVE_FUTURE_DATA より小さい値に変化するためです。

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

1. メディア要素に loop 属性が指定されており、現在のメディア・コントローラがなければ、そのメディア・リソースの巻き戻し限界位置にシークして、これらの手順を中止します。

2. 再生を停止します。

   ended 属性が true になります。

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

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

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

1. 再生を停止します。

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

defaultPlaybackRate 属性は、メディア・リソースを再生させたい速度を与えます。これは、その本来の速度の倍数です。この属性はミュータブルです。取得時においては、それにセットされた最後の値を返さなければいけません。まだセットされていなければ 1.0 を返さなければいけません。セット時においては、この属性は新たな値にセットされなければいけません。

defaultPlaybackRate は、ユーザーエージェントがユーザーにユーザー・インタフェースを見せる場合に使います。

playbackRate 属性は実効再生レートを与えます（それを置き換える現在のメディア・コントローラが無いとと仮定します）。これは、メディア・リソースが再生する速度のことで、その本来の速度の倍数です。これが defaultPlaybackRate と同じでなければ、ユーザーが早送りやスロー・モーション再生といった機能を使っていることになります。この属性はミュータブルです。取得時においては、最後にセットされた値を返さなければいけません。まだセットされていなければ 1.0 を返さなければいけません。セット時においては、この属性は新た値にセットされ、その再生の速度が変化します（この要素が潜在的に再生中で、かつ、現在のメディア・コントローラが無い場合）。

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

defaultPlaybackRate と playbackRate 属性は、メディア要素に現在のメディア・コントローラがあるときは、何も作用しません。代わりに、MediaController オブジェクトの同じ名前の属性が、その状況で使われます。

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

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

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

2. 再生が終了し、再生方向が前進であり、かつ、そのメディア要素に現在のメディア・コントローラが無いなら、そのメディア・リソースの巻き戻し限界位置にシークします。

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

3. メディア要素に現在のメディア・コントローラがあれば、そのメディア要素を、その新たなメディア・コントローラのスピードまで引き上げます。

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

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

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

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

      そうでなければ、そのメディア要素の readyState 属性の値が HAVE_FUTURE_DATA, HAVE_ENOUGH_DATA なら、その要素で playing という名前のシンプルなイベントを発出するタスクをキューイングします。

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

6. そのメディア要素に現在のメディア・コントローラがあるなら、そのメディア要素の現在のメディア・コントローラのコントローラ状態を報告します。

pause() メソッドが呼び出されたときに、さらに、ユーザーエージェントがメディア要素を停止する必要があるとき、ユーザーエージェントは次の手順を実行しなければいけません：

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

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

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

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

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

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

4. そのメディア要素に現在のメディア・コントローラがあるなら、そのメディア要素の現在のメディア・コントローラのコントローラ状態を報告します。

実効再生レートは必ずしもその要素の playbackRate であるとは限りません。メディア要素に現在のメディア・コントローラがあるとき、その実効再生レートは、その MediaController のメディア・コントローラ再生レートとなります。そうでなければ、その実効再生レートは、単にその要素の playbackRate となります。このように、現在のメディア・コントローラは、そのメディア要素より優先されます。

もし実効再生レートが正の値かゼロなら、その再生方向は前進となります。そうでなければ、後進となります。

メディア要素が潜在的に再生中で、その Document が完全にアクティブな Document であるとき、その現在再生位置は、そのメディア・タイムラインのクロックの単位時間で刻まれたメディア時間の実効再生レートの単位で、単調に増えていかなければいけません。

実効再生レートは 0.0 になることがあります。これは、再生が停止されていないにも関わらず、現在再生位置が動いていない場合です（paused は true にならず、pause イベントは発出されません ）。

本仕様は、ユーザーエージェントが適切な再生レートを実現する方法を定義しません。これは、利用可能なプロトコルやメディアに依存します。そして、ユーザーエージェントは適切なレートでメディア・データをサーバーに提供してもらうために、サーバーとネゴシエートするのが妥当と言えます。そうすることで、（レートが変わったときと、サーバーがストリームの再生レートを変更したときの間の期間を除いて）クライアントは、実際にフレームを落としたり挿入する必要が無くなります。

再生方向が後進のとき、対応のオーディオはミュートしなければいけません。実効再生レートが、ユーザーエージェントが普通にオーディオを再生することができないほどに低いか高いときも、対応のオーディオをミュートしなければいけません。実効再生レートが 1.0 でなければ、ユーザーエージェントは、適切なレンダリングのために必要に応じて、そのオーディオにピッチ調整を適用することができます。

潜在的に再生中のメディア要素が Document に存在しなければ、ビデオを再生してはいけません。しかし、オーディオ・コンポーネントは再生するべきです。メディア要素は、自身へ向けられたリファレンスすべてが削除されたという理由だけで再生を停止してはいけません。メディア要素にもうこれ以上に再生されるオーディオがないという状態になって初めて、その要素をガーベッジ・コレクションの対象にすることができるのです。

たとえ要素がまだ再生中になっていなくても、そういった要素に、オーディオを再生する明確なリファレンスがひとつも存在しないということはあり得ます：例えば、まだリファレンスを持ちつつもまだ停止はしていない現在のメディア・コントローラを持つことが考えられます。また、停止はしていないのにもかかわらずコンテンツを待ちそびれてバッファに入れることができないということも考えられます。

メディア要素の現在再生位置が変わるとき（例えば、再生やシークによって）、ユーザーエージェントは次の手順を実行しなければいけません。もし現在再生位置がこの手順の実行中に変わるなら、ユーザーエージェントはこの手順が完了するのを待ち、その直後にこの手順を再実行しなければいけません。（ゆえに、この手順は可能な限り必要に応じて頻繁に実行されます。もし一回の反復に時間がかかってしまうと、ユーザーエージェントが急いで "追いつこう" とするので、あるキューがスキップされてしまうことになります。）

1. current cues をキューの順序リストとします。これは、メディア要素（無効になっていないもの）のすべてのキューを含んだ状態で初期化されます。hidden、showing、Showing by defaultのテキスト・トラックすべてが対象です。ただし、開始時刻が現在再生位置より前か等しく、かつ、終了時刻が現在再生位置より後となるものに限ります。これは、テキスト・トラック・キュー順です。

2. other cues をキューの順序リストとします。これは、メディア要素のすべてのキューを含んだ状態で初期化されます。hidden、showing、showing by defaultのテキスト・トラックすべてが対象です。ただし、current cues には存在しないものに限ります。これもテキスト・トラック・キュー順です。

3. 通常再生中に、現在再生位置の通常の単調増加を通して時間が到達したなら、かつ、ユーザーエージェントが過去 15 ～ 20 ミリ秒に該当の要素で timeupdate イベントを発出しておらず、そういったイベントのイベント・ハンドラをまだ実行していないのであれば、ユーザーエージェントは、その要素で timeupdate という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。（例えば、明示的なシークなど、上記に該当しない場合、現在再生位置が変化する全体的な処理の一環で、関連のイベントが発出されます。）

   ゆえに、イベントは 66Hz 程度よりも早く、または、4Hz より遅く発出されることはありません（イベント・ハンドラーが実行に 250 ミリ秒より長くかからないと仮定）。ユーザーエージェントは、都度、システム負荷と、イベント処理の平均コストに基づいて、イベントの周期を変えることが推奨されます。そうすることで、ユーザーエージェントがビデオをデコードしている間でも、UI アップデートを無理なく処理できるようになります。

4. current cues のキューすべてにテキスト・トラック・キュー・アクティブ・フラグがセットされ、other cues のキューのいずれにもテキスト・トラック・キュー・アクティブ・フラグがセットされていなければ、これらの手順を中止します。

5. 通常再生中に、現在再生位置の通常の単調増加を通して時間が到達し、かつ、other cues に、テキスト・トラック・キュー・アクティブ・フラグとテキスト・トラック・キュー終了停止フラグの両方がセットされたキューがあるなら、すぐにメディア要素を停止します。（例えば、明示的なシークなど、上記に該当しない場合、キューの終了時間を超えることで再生が停止することはありません。たとえ、そのキューにテキスト・トラック・キュー終了停止フラグがセットされていたとしてもです。）

6. affected tracks を、テキスト・トラックのリストとします。最初は空です。

7. other cues の中にあるテキスト・トラック・キュー・アクティブ・フラグがセットされたテキスト・トラック・キューそれぞれに対して、リストの順番で、TextTrackCue オブジェクトで exit という名前のシンプルなイベントを発出するタスクをキューイングします。そして、もしそれがまだリストの中になければ、affected tracks にそのキューのテキスト・トラックを追加します。

8. current cues の中にあるテキスト・トラック・キュー・アクティブ・フラグがセットされていないテキスト・トラック・キューそれぞれに対して、リストの順番で、TextTrackCue オブジェクトで enter という名前のシンプルなイベントを発出するタスクをキューイングします。そして、もしそれがまだリストの中になければ、affected tracks にそのキューのテキスト・トラックを追加します。

9. affected tracks のテキスト・トラックそれぞれに対して、リストに追加された順番（これは、メディア要素のテキスト・トラック・リストにあるテキスト・トラックの相対的な順番と一致します）で、TextTrack オブジェクトでcuechange という名前のシンプルなイベントを発出するタスクをキューイングします。そして、そのテキスト・トラックと対応付けられた track 要素があるなら、その track 要素でも、cuechange という名前のシンプルなイベントを発出します。

10. current cues にあるすべてのキューのテキスト・トラック・キュー・アクティブ・フラグをセットし、other cues にあるすべてのキューのテキスト・トラック・キュー・アクティブ・フラグを解除します。

11. affected tracks の中で、showing、または、showing by defaultとなっている各テキスト・トラックのテキスト・トラック・レンダリング・アップデート規則を実行します。

前述のアルゴリズムの観点では、テキスト・トラック・キューは、テキスト・トラックの一部と見なされます。ただし、それがキューのテキスト・トラック・リストにリストされているだけならです。それがテキスト・トラックと関連づけられるにすぎないならではありません。

メディア要素の Document が完全にアクティブなドキュメントでなくなれば、そのドキュメントが再びアクティブになるまで再生は停止します。

メディア要素が Document から削除されるとき、ユーザーエージェントは次の手順を実行しなければいけません：

1. 非同期に安定状態を待機し、Document のメディア要素を削除したタスクが継続できるようにします。同期セクションは、このアルゴリズムの残りの手順すべてとなります。（同期セクションの手順は ⌛ でマーキングされています）

2. ⌛ メディア要素が Document の中ににあれば、これらの手順を中止します。

3. ⌛ メディア要素の networkState 属性の値が NETWORK_EMPTY なら、これらの手順を中止します。

4. ⌛ メディア要素を停止します。

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

ユーザーエージェントがメディア・リソースの特定の new playback position（新たな再生位置）にシークする必要があるとき、それは、ユーザーエージェントは次の手順を実行しなければいけないことを意味します。このアルゴリズムは、イベント・ループ・メカニズムと密接に作用しあいます。とりわけ、これには同期セクションがある点です（イベント・ループ・アルゴリズムの一環で呼び出されます）。そのようなセクションにおける手順には、このマークを付けてあります。 ⌛

1. メディア要素の readyState が HAVE_NOTHING なら、INVALID_STATE_ERR 例外を発出し（シークが DOM メソッド呼び出し、または、IDL 属性のセットによるものだった場合）、これらの手順を中止します。

2. 要素の seeking IDL 属性が true なら、このアルゴリズムの別のインスタンスはすでに実行中です。このアルゴリズムのその別のインスタンスを中止します。完了に至るまでに実行している手順を待ちません。

3. seeking IDL 属性を true にセットします。

4. シークが DOM メソッドの呼び出し、または、IDL 属性のセットによるものだったなら、スクリプトを継続します。これらの手順の残りは非同期に実行されなければいけません。xxx というマークが付けられた手順を除いて、これらは、このアルゴリズムを呼び出す別のインスタンスによって、いつでも、中止される可能性があります。

5. new playback position がメディア・リソースの終わりより後なら、それをそのメディア・リソースの終わりとします。

6. new playback position が巻き戻し限界位置より前なら、それをその位置とします。

7. （変わったばかりかもしれませんが）new playback position が seekable 属性の範囲のいずれにも含まれないなら、それを、seekable 属性の範囲のうち、new playback position に最も近い範囲の位置とします。この制約を満たす位置が 2 つあったら（つまり、new playback position が seekable 属性の 2 つの範囲のちょうど中間）、現在再生位置に近い方の位置を使います。seekable 属性に範囲が一つもなければ、seeking IDL 属性を false にセットして、これらの手順を中止します。

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

9. 現在再生位置を、指定の new playback position にセットします。

   シークを開始する直前にメディア要素が潜在的に再生中だったけれども、シークによって readyState 属性が HAVE_FUTURE_DATA より小さい値に変わってしまったら、その要素で waiting が発出されます。

10. ユーザーエージェントが new playback position のメディア・データが利用可能かどうかを確定できるまで待ちます。もし利用可能なら、デコードが完了してその位置の再生が可能となるまで待ちます。

11. 安定状態を待ちます。同期セクションは、このアルゴリズムの残りの手順すべてとなります。（同期セクションの手順は ⌛ でマーキングされています。）

12. ⌛ seeking IDL 属性を false にセットします。

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

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

seekable 属性は、メディア・リソースの範囲を表す新たな静的な正規化 TimeRanges オブジェクトがあれば、それを返さなければいけません。これは、この属性が評価された時点において、ユーザーエージェントがシーク可能な範囲を指します。

単純な動画ファイルで、ユーザーエージェントとサーバーが HTTP Range リクエストをサポートしているといった理由で、ユーザーエージェントがメディア・リソースのどこにでもシークできるのであれば、この属性はひとつの範囲を伴ったオブジェクトを返すでしょう。この範囲の開始は最初のフレームの時間（巻き戻し限界位置、通常はゼロ）であり、最後は最初のフレームの時間に duration 属性の値（最後のフレームの時間と同じでしょうが、正の Infinity となる場合もあります）を加えたのと同じです。

その範囲は連続的に変わり続けるかもしれません。例えば、ユーザーエージェントが無限ストリームでスライディング・ウィンドウをバッファリングしている場合です。これは、例えば、DVR を使ってテレビの生放送を視聴したときに見られる挙動です。

メディア・リソースは内部的にスクリプトされておりインタラクティブな場合があります。ゆえに、メディア要素が非線形に再生されることが考えられます。もしこれが起こったら、ユーザーエージェントは、現在再生位置が不連続に変わるとき、シークのアルゴリズムが使われたかのように振る舞わなければいけません（そうすることで、関連のイベントが発出します）。メディア要素に現在のメディア・コントローラがあれば、ユーザーエージェントは、代わりに適切にメディア・コントローラをシークしなければいけません。

メディア要素の audioTracks 属性は、メディア要素のメディア・リソースの中で利用可能なオーディオ・トラックを表す MultipleTrackList オブジェクトを返さなければいけません。このオブジェクトはライブです。いつでも同じオブジェクトが返されなければいけません。

メディア要素の videoTracks 属性は、メディア要素のメディア・リソースの中で利用可能なビデオ・トラックを表す ExclusiveTrackList オブジェクトを返さなければいけません。このオブジェクトはライブです。いつでも同じオブジェクトが返されなければいけません。

ひとつのメディア要素につき、TrackList オブジェクトは 2 つしかありません（ひとつは MultipleTrackList オブジェクトで、もうひとつは ExclusiveTrackList オブジェクトです）。たとえ、他のメディア・リソースが該当の要素にロードされたとしてもです。このオブジェクトは再利用されます。

length 属性は、取得の時点で TrackList オブジェクトによって表されるトラック数を返さなければいけません。

TrackList オブジェクトにあるトラックは、抜けがないよう順に並べられなければいけません。メディア・リソースが順序を定義するフォーマットにあるなら、その順番が使われなければいけません。そうでなければ、その順番は、トラックがメディア・リソースの中で宣言された相対的順序でなければいけません。最初のインデックスは 0 で、以降のトラックは、前のより 1 だけ大きい順番が割り振られます。

getID(index) メソッドは、インデックスが index となるトラックがあれば、その識別子を返さなければいけません。該当するトラックがなければ、このメソッドは INDEX_SIZE_ERR 例外を投げなければいけません。メディア・リソースが Media Fragments URI のフラグメント識別子構文をサポートするフォーマットにあるなら、返される識別子は、そのようなフラグメント識別子のトラック次元でトラック名として使ったら、そのトラックを有効にするであろう識別子と同じでなければいけません。 [MEDIAFRAG]

getKind(index) メソッドは、インデックスが index となるトラックがあれば、そのカテゴリーを返さなければいけません。無ければ、このメソッドは INDEX_SIZE_ERR 例外を投げなければいけません。

トラックのカテゴリーは下表の最初の列に入れられた文字列ですが、それは、この表の二番目と三番目の列の定義に基づいたトラックに最も適していることを表しています。これは、メディア・リソースのトラックに含まれるメタデータによって決定されます。Ogg ファイルでは、トラックの Role ヘッダーから関連のメタデータを取得できます。三番目の列にあるセルは、同じ行の最初の列にあるセルに入れられたカテゴリーは何に適用されるのかを言っています。カテゴリーがオーディオ・トラックに適用されるなら、それはオーディオ・トラックにのみ適しています。そして、カテゴリーがビデオ・トラックに適用されるなら、それはビデオ・トラックにのみ適しています。

getLabel(index) メソッドは、インデックスが index となるトラックがあり、それにラベルがあれば、そのラベルを返さなければいけません。そのようなトラックがなければ、このメソッドは INDEX_SIZE_ERR 例外を投げなければいけません。インデックスが index となるトラックがあるけれども、それにラベルがなければ、このメソッドは空文字列を返さなければいけません。

getLanguage(index) メソッドは、インデックスが index となるトラックがあり、それに言語があれば、その言語を表す BCP 47 言語タグを返さなければいけません。そのようなトラックがなければ、このメソッドは INDEX_SIZE_ERR 例外を投げなければいけません。インデックスが index となるトラックがあるけれども、それに言語が無い、または、ユーザーエージェントが BCP 47 言語タグとしてその言語を表現することができない（例えば、メディア・リソースのフォーマットの言語情報が、規定外の自由形式の文字列を許している）のであれば、このメソッドは空文字列を返さなければいけません。

MultipleTrackList オブジェクトは、同時に複数のトラックを有効にできるトラック・リストを表します。各トラックは有効か無効のいずれかになります。

isEnabled(index) メソッドは、インデックスが index となるトラックがあり、かつ、それがその時点で有効であれば、true を返さなければいけません。インデックスが index となるトラックがあるけれども、それがその時点で無効なのであれば、false を返さなければいけません。インデックスが index となるトラックが無ければ、INDEX_SIZE_ERR 例外を投げなければいけません。

enable(index) メソッドは、インデックスが index となるトラックがあれば、それを有効にしなければいけません。無ければ、INDEX_SIZE_ERR 例外を投げなければいけません。

disable(index) メソッドは、インデックスが index となるトラックがあれば、それを無効にしなければいけません。無ければ、INDEX_SIZE_ERR 例外を投げなければいけません。

トラックが有効か無効になるとき、ユーザーエージェントは、MultipleTrackList オブジェクトで change という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

ExclusiveTrackList オブジェクトは、一度にひとつのトラックしか選択できないトラック・リストを表します。

selectedIndex 属性は、現在選択されているトラックのインデックスを返さなければいけません。ExclusiveTrackList オブジェクトがどのトラックも表していないのであれば、-1 を返さなければいけません。

select(index) は、インデックスが index となるトラックがあれば、それを選択して、前に選択されていたトラックを非選択にしなければいけません。インデックスが index となるトラックが無ければ、INDEX_SIZE_ERR 例外を投げなければいけません。

選択トラックが変わったら、ユーザーエージェントは、MultipleTrackList オブジェクトで change という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

次は、TrackList インタフェースを実装するすべてのオブジェクトによって、IDL 属性として、サポートされなければならないイベント・ハンドラー（そして、それに関連するイベント・ハンドラのイベント・タイプ）です:

本セクションで挙げたタスクに対するタスク・ソースは、DOM 操作タスク・ソースです。

メディア要素は現在のメディア・コントローラを持つことができます。これは、MediaController オブジェクトのことです。メディア要素が mediagroup 属性を伴わずに生成されるときは、現在のメディア・コントローラを持ちません。（そういった属性を伴って生成されれば、後述の通り、この属性は現在のメディア・コントローラを初期化します。）

MediaController の従属メディア要素とは、現在のメディア・コントローラがその MediaController となるメディア要素のことです。MediaController のすべての従属メディア要素は、メディア・タイムラインの単位時間の定義に同じクロックを使わなければいけません。

メディア要素の controller 属性は、取得時においては、その要素に現在のメディア・コントローラがあれば、それを返し、なければ null を返さなければいけません。セット時においては、まず、その要素に mediagroup 属性があれば、それを削除し、そして、その現在のメディア・コントローラを指定の値にセットしなければいけません。指定の値が null なら、その要素の現在のメディア・コントローラは無くなります。null でなければ、ユーザーエージェントは、その新たなメディア・コントローラを使って、そのメディア要素のスピードを合わせなければいけません。

MediaController() コンストラクタは、呼び出されたら、新たに生成された MediaController オブジェクトを返さなければいけません。

seekable 属性は、新たな静的な正規化 TimeRanges オブジェクトを返さなければいけません。これは、ユーザーエージェントが、この属性を評価した時点で、従属メディア要素のメディア・リソースのうち、シーク可能な範囲の共通部分を表します。

buffered 属性は、新たな静的な正規化 TimeRanges オブジェクトを返さなければいけません。これは、ユーザーエージェントが、この属性を評価した時点で、従属メディア要素のメディア・リソースのうち、すでにバッファ済みの範囲の共通部分を表します。ユーザーエージェントは、その範囲が利用可能かを正確に判定しなければいけません。たとえ、面倒な調査をしなければ判定できないようなメディア・ストリームだったとしてもです。

duration は、メディア・コントローラの尺を返さなければいけません。

15 ～ 250 ミリ秒ごと、または、MediaController のメディア・コントローラの尺が変わるたびに、どちらが発生しても最短の頻度で、ユーザーエージェントは、その MediaController で durationchange という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。MediaController のメディア・コントローラの尺が減っていき、そのメディア・コントローラの位置が、そのメディア・コントローラの尺より大きくなれば、ユーザーエージェントは、即座にそのメディア・コントローラをメディア・コントローラの尺にシークしなければいけません。

currentTime 属性は、取得時においては、メディア・コントローラの位置を返さなければいけません。そして、セット時においては、メディア・コントローラを新たな値にシークしなければいけません。

15 ～ 250 ミリ秒ごと、または、MediaController のメディア・コントローラの位置が変わるたびに、どちらが発生しても最短の頻度で、ユーザーエージェントは、その MediaController で timeupdate という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

MediaController が生成されるとき、それは再生中メディア・コントローラとなります。それは、停止中メディア・コントローラに変わることもありますし、ユーザーエージェントのユーザー・インタフェース（その要素がユーザーにユーザー・インタフェースを表示している場合）や、本セクション（後述します）で定義している API を使ったスクリプトのいずれかを通して、戻ることもあります。

paused 属性は、MediaController が停止中メディア・コントローラなら true を返し、そうでなければ false を返します。

played 属性は、新たな静的な正規化 TimeRanges オブジェクトを返さなければいけません。これは、ユーザーエージェントが、この属性を評価した時点で、従属メディア要素のメディア・リソースのうち、すでにレンダリングした範囲の和集合を表します。

pause() メソッドが呼び出されたとき、その MediaController が再生中メディア・コントローラなら、ユーザーエージェントは、その MediaController を停止中メディア・コントローラに変更し、その MediaController で pause という名前のシンプルなイベントを発出するタスクをキューイングし、そして、その MediaController のコントローラの状態を報告しなければいけません。

play() メソッドが呼び出されるとき、その MediaController が停止中メディアコントローラなら、ユーザーエージェントは、その MediaController を再生中メディア・コントローラに変更し、その MediaController で play という名前のシンプルなイベントを発出するタスクをキューイングし、そして、その MediaController のコントローラの状態を報告しなければいけません。

MediaController には、メディア・コントローラ・デフォルト再生レートとメディア・コントローラ再生レートがあります。これらはいずれも、その MediaController が生成されるときに 1.0 にセットされなければいけません。

defaultPlaybackRate 属性は、取得時においては、その MediaController のメディア・コントローラ・デフォルト再生レートを返さなければいけません。取得時においては、その MediaController のメディア・コントローラ・デフォルト再生レートを新たな値にセットし、その MediaController で ratechange という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

playbackRate 属性は、取得時においては、その MediaController のメディア・コントローラ再生レートを返さなければいけません。取得時においては、その MediaController のメディア・コントローラ再生レートを新たな値にセットし、その MediaController で ratechange という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

MediaController は、メディア・コントローラ音量乗数を持ちます。これは、その MediaController オブジェクトが生成されるときに 1.0 にセットされなければいけません。さらに、メディア・コントローラ・ミュート・オーバーライドを持ちますが、これは false で初期化されなければいけません。

volume 属性は、取得時においては、MediaController のメディア・コントローラ音量乗数を返さなければいけません。そして、セット時においては、新たな値が 0.0 ～ 1.0 の範囲内であれば、その MediaController のメディア・コントローラ音量乗数を、その新たな値にセットし、その MediaController で volumechange という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。新たな値が 0.0 ～1.0 の範囲外なら、セット時に、INDEX_SIZE_ERR 例外が発出されなければいけません。

muted 属性は、取得時においては、その MediaController のメディア・コントローラ・ミュート・オーバーライドを返さなければいけません。そして、セット時においては、その MediaController のメディア・コントローラ・ミュート・オーバーライドを新たな値にセットし、その MediaController で volumechange という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

MediaController のすべての従属メディア要素のメディア・リソースは、それぞれのゼロ時間の間の相対的なオフセットを提供する定義済みの一時的な関係性を持ちます。タイムライン・オフセットを持つメディア・リソースでは、その相対的なオフセットは、そのタイムライン・オフセット間の差となります。タイムライン・オフセットを持たないすべてのメディア・リソースのゼロ時間は、お互いからのオフセットではありません（つまり、そのタイムラインの起源は相互に一時的なものとなります。）。そして、最後に、最も前のタイムライン・オフセットを持つメディア・リソースのゼロ時間（もしあれば）は、タイムライン・オフセットを持たないメディア・リソースのゼロ時間からのオフセットではありません（つまり、タイムライン・オフセットを持たないメディア・リソースの起源は、最も前のタイムライン・オフセットを持つメディア・リソースのタイムライン上の最も前の定義済み地点を使って、さらに相互に一時的なものとなります）。

メディア要素にあるメディア・リソースのメディア・リソース最終地点とは、次の通りに定義されます：メディア・リソースが有限で尺が分かるのであれば、そのメディア・リソース最終地点は、そのメディア・リソースのタイムラインの尺（そのタイムライン上の最後の定義済み地点）となります。そうでなければ、そのメディア・リソースの尺は無限で不明となり、そのメディア・リソース最終地点は、その時点でメディア・リソースにとって利用可能なメディア・データの最後のフレームの時間となります。

各 MediaController には、それ自身にも定義済みタイムラインがあります。このタイムラインでは、その MediaController のすべての従属メディア要素のすべてのメディア・リソースは、定義済みオフセットによって一時的に並べられます。MediaController のメディア・コントローラの尺とは、最も手前となる巻き戻し可能位置からの時間です。これは、この MediaController のタイムラインと相対的で、その MediaController の従属メディア要素のメディア・リソースのいずれかのものとなり、その MediaController の数ある従属メディア要素のメディア・リソースのうち最後のメディア・リソース最終地点の時間までで、これも、この MediaController のタイムラインから相対的となります。

各 MediaController にはメディア・コントローラ位置があります。これは、ユーザーエージェントが従属メディア要素を再生しようとしている MediaController のタイムライン上にあります。MediaController が生成されるとき、そのメディア・コントローラ位置は最初はゼロになります。

ユーザーエージェントが、メディア要素を新たなメディア・コントローラのスピードに合わせることになったとき、そのメディア要素を、そのメディア要素のタイムラインから見て、その MediaController のメディア・コントローラ位置にシークしなければいけません。その結果で例外が発生しても破棄します。

ユーザーエージェントが特定の new playback position にメディア・コントローラをシークすることになったとき、これらの手順に従わなければいけません：

1. new playback position が 0 未満なら、それを 0 にセットします。

2. new playback position がメディア・コントローラの尺より大きければ、それをメディア・コントローラの尺にセットします。

3. メディア・コントローラ位置を new playback position にセットします。

4. それぞれの従属メディア要素を、そのメディア要素のタイムラインから見て new playback position にシークします。その結果で例外が発生しても破棄します。

MediaController が停止中メディア・コントローラである、または、その従属メディア要素にブロックされたメディア要素がある、または、自動再生フラグが true の従属メディア要素のうち、その paused 属性が true のままになっているものがある、または、従属メディア要素のすべての paused 属性が true にセットされているなら、その MediaController のことをブロックされたメディア・コントローラと言います。

MediaController がブロックされたメディア・コントローラである、または、そのメディア・コントローラの位置が、その MediaController のタイムラインから見て、そのメディア・リソースの巻き戻し限界位置より前である、または、その MediaController のタイムラインから見て、そのメディア・リソースの最後より後ろであるなら、そのメディア要素は、そのメディア・コントローラでブロックされていると言います。

MediaController がブロックされたメディア・コントローラではなく、かつ、Document が完全にアクティブな Document となる従属メディア要素を少なくとも一つ持つとき、その MediaController のメディア・コントローラ位置は、単調に増えていかなければいけません。ただし、その従属メディア要素が使っているクロックの単位時間を持った MediaController のタイムライン上で、メディア・コントローラ再生レートの時間単位で増えていかなければいけません。

MediaController のタイムライン上のゼロ地点が、従属メディア要素のタイムラインと 時間差 ΔT で動くとき、その MediaController のメディア・コントローラ位置は ΔT だけ減らされなければいけません。

例えば、バッファリングなしにライブ・ストリームを再生するときなど、ある状況においては、そのメディア・コントローラ位置は単調に増えていくでしょう。前述の通り、前の段落で説明した ΔT と同じレートになり、結果的に、すべての意図と目的のため、そのメディア・コントローラ位置は、一定のままに見えるでしょう（恐らく値は 0 です）。

MediaController は、直前に報告された読取状態というものを持ちます。これは 0 ～ 4 までの数値となり、該当のメディア要素の readyState 属性に使われる数値に相当します。直前に報告された再生状態とは、playing、waiting、ended のいずれかのことです。

MediaController が生成されるとき、その直近に報告された読取状態は 0 にセットされなければいけません。そして、その直近に報告された再生状態は waiting にセットされなければいけません。

ユーザーエージェントが MediaController に対してコントローラ状態を報告する必要があるとき、ユーザーエージェントは次の手順を実行しなければいけません：

1. MediaController に従属メディア要素が無ければ、new readiness state を 0 にセットします。

   そうでなければ、すべての従属メディア要素の readyState IDL 属性のうち、最も低い値にセットします。

2. MediaController の直近に報告された読取状態が、new readiness state と等しくないなら、該当の MediaController オブジェクトでシンプルなイベントを発出するタスクをキューイングします。このイベントの名前は下表にある new readiness state の値に相当するイベント名になります：

   new readiness state の値	イベント名
   0	emptied
   1	loadedmetadata
   2	loadeddata
   3	canplay
   4	canplaythrough

3. MediaController の直近に報告された読取状態を、new readiness state とします。

4. new playback state を、次のリストの中から最初に一致する条件に指定された状態にセットして、初期化します：

   MediaController に従属メディア要素が無い場合

   new playback state を waiting とします。

   MediaController の従属メディア要素のすべてが再生終了となっており、かつ、メディア・コントローラ再生レートが 0 以上の場合

   new playback state を ended とします。

   MediaController がブロックされたメディア・コントローラの場合

   new playback state を waiting とします。

   いずれにも該当しない場合

   new playback state を playing とします。

5. MediaController の直近に報告された再生状態が new playback state に等しくないなら、該当の MediaController オブジェクトでシンプルなイベントを発出するタスクをキューイングします。その名前は、new playback state が playing なら playing となり、new playback state が ended なら ended となり、それ以外の場合は waiting となります。

6. MediaController の直近に報告された再生状態を、new playback state とします。

次は、サポートされなければいけないイベント・ハンドラです。これは MediaController インタフェースを実装するすべてのオブジェクトで、IDL 属性としてサポートされなければいけません：

本セクションに挙げたタスクに対するタスク・ソースは、DOM マニピュレーション・タスク・ソースです。

メディア要素が mediagroup 属性を伴って生成されるとき、そして、mediagroupの mediagroup 属性がセット、変更、削除されるとき、ユーザーエージェントは次の手順を実行しなければいけません：

1. m を該当のメディア要素とします。

2. m にメディア・コントローラがあれば、現在のメディア・コントローラを持たせません。

3. m の mediagroup 属性が削除されているなら、これらの手順を中止します。

4. Document が m の Document と同じ（たとえ、これらの要素のひとつまたは両方が、実際にその Document の中にないとしてもです）であり、かつ、mediagroup 属性も持ち、かつ、mediagroup 属性が m の mediagroup 属性の新たな値と同じ値を持つ別のメディア要素があるなら、controller を、そのメディア要素の現在のメディア・コントローラとします。

   なければ、controller を新たに生成された MediaController とします。

5. m の現在のメディア・コントローラを controller とします。

6. メディア要素を、その新メディア・コントローラの速度に合わせます。

メディア要素の mediaGroup IDL 属性は、mediagroup コンテンツ属性を反映しなければいけません。

このようなデータの処理やレンダリングの規則は、関連の仕様で定義されています。例えば、メディア・リソースがビデオであれば、そのビデオ形式の仕様です。

ユーザーエージェントがテキスト・トラックと等価であると認識できサポートしているデータをメディア・リソースが含んでいるとき、次のように、ユーザーエージェントは、その関連データを使って、メディア・リソース固有のテキスト・トラック公開する手順を実行します：

1. 関連データを、新たなテキスト・トラックと、それに相当する新たな TextTrack オブジェクトに関連付けます。そのテキスト・トラックが、メディア・リソース固有のテキスト・トラックです。

2. 新たなテキスト・トラックの種別とラベルと言語を、関連データのセマンティクスに基づいて、セットします。これは関連仕様で定義されているものです。

3. 新たなテキスト・トラックのキュー・リストを、その時点で解析されたキューを使って装着します。キュー公開のガイドラインに従います。そして、必要に応じてそれを動的にアップデートします。

4. 新たなテキスト・トラックの読取状態を、現在の状態を最も正確に表す値にセットし、必要に応じて、それを動的にアップデートし始めます。

   例えば、メディア・リソースの関連データがすべて解析され、完全にキューを表すことができるのであれば、そのテキスト・トラックは loaded になります。一方、キューのデータがメディア・データと交互に配置されており、そのメディア・リソース全体がまだダウンロードされていないのであれば、loading 状態のほうが正確と言えるでしょう。

5. 新たなテキスト・トラックのモードを、ユーザー設定や、そのデータの関連仕様の要件に一致するモードにセットします。

6. テキスト・トラック・キュー・リストを空にして、それを該当の形式に適したテキスト・トラック・レンダリング・アップデート規則と関連付けます。

7. 新たなテキスト・トラックを、メディア要素のテキスト・トラック・リストに追加します。

メディア要素が、メディア要素のメディア・リソース固有のテキスト・トラックを忘れることになったら、ユーザーエージェントは、そのメディア要素のテキスト・トラック・リストから、すべてのメディア・リソース固有のテクスト・トラックを削除しなければいけません。

4.8.10.12.3 帯域外テキスト・トラックの抽出

track 要素が生成されるとき、それは、新たなテキスト・トラック（後で定義する通り、その値を使います）と、それに相当する新たな TextTrack オブジェクトに関連付けられなければいけません。

テキスト・トラック種別は、下表の通り、要素の kind 属性の状態から決定されます。最初のカラムのセルにある状態に対応する種別は、その次のカラムにある文字列となります：

テキスト・トラック・ラベルは、その要素のトラック・ラベルです。

テキスト・トラック言語は、その要素のトラック言語です。なければ空文字列です。

kind, label, srclang 属性がセット、変更、削除されたら、テキスト・トラックは、前述の定義従って、適切にアップデートしなければいけません。

トラック URL の変更は、後述のアルゴリズムで扱われます。

テキスト・トラック・キュー・リストは最初は空です。参照ファイルが解析できたら動的に変わります。該当の形式に適したテキスト・トラック・レンダリングをアップデートする規則によってリストと関連付けられます。WebVTT なら、WebVTT テキスト・トラックの表示をアップデートする規則です。

track 要素の親要素が変わり、新たな親がメディア要素なら、ユーザーエージェントは、そのメディア要素のテキスト・トラック・リストに、track 要素に相当するテキスト・トラックを追加しなければいけません。

track 要素の親要素が変わり、古い親がメディア要素だったなら、ユーザーエージェントは、そのメディア要素のテキスト・トラック・リストから、track 要素に相当するテキスト・トラックを削除しなければいけません。

track 要素に相当するテキスト・トラックがメディア要素のテキスト・トラック・リストに追加されるとき、ユーザーエージェントはテキスト・トラック・モードを適切にセットしなければいけません。次の条件によって決定します：

テキスト・トラック種別が subtitles か captions で、かつ、ユーザーが、テキスト・トラック種別、テキスト・トラック言語、テキスト・トラック・ラベルを使ってトラックを有効にすることに興味を示し、かつ、メディア要素のテキスト・トラック・リストに、テキスト・トラック・モードが showing で、テキスト・トラック種別が subtitles か captions のテキスト・トラックが他に無い場合

テキスト・トラック種別が descriptions で、かつ、ユーザーが、テキスト・トラック言語、テキスト・トラック・ラベルを使ってテキスト記述を有効にすることに興味を示し、かつ、メディア要素のテキスト・トラック・リストに、テキスト・トラック・モードが showing で、テキスト・トラック種別が descriptions のテキスト・トラックが他に無い場合

テキスト・トラック種別が chapters で、かつ、テキスト・トラック言語は、ユーザーエージェントがユーザーにとって適切だと信じるに値する理由を持てる言語であり、かつ、メディア要素のテキスト・トラック・リストに、テキスト・トラック・モードが showing で、テキスト・トラック種別が chapters のテキスト・トラックが他に無い場合

テキスト・トラック・モードを showing とします。

メディア要素のテキスト・トラック・リストに、テキスト・トラック・モードが showing by default となるテキスト・トラックがあれば、ユーザーエージェントは、さらに、そのテキスト・トラックのテキスト・トラック・モードを hidden に変更しなければいけません。

track 要素に default 属性が指定され、メディア要素のテキスト・トラック・リストに、テキスト・トラック・モードが showing か showing by default となるテキスト・トラックが他にない場合

テキスト・トラック・モードを showing by default とします。

該当しない場合

テキスト・トラック・モードを disabled とします。

track 要素に相当するテキスト・トラックが、テキスト・トラック・モードに hidden, showing, showing by default のいずれかがセットされて生成されるとき、そして、track 要素に相当するテキスト・トラックが、テキスト・トラック・モードに disabled がセットされて生成され、続いて、そのテキスト・トラック・モードが hidden, showing, showing by default のいずれかに初めて変更されるとき、ユーザーエージェントは、すぐに同期で次のアルゴリズムを実行しなければいけません。このアルゴリズムは、イベント・ループ・メカニズムに密接に作用します。とりわけ、同期セクション（イベント・ループ・メカニズ・アルゴリズムの一環で呼び出されます）がある点です。そのセクションの手順には ⌛ がマーキングされています。

1. テキスト・トラック読取状態を loading にセットします。

2. URL を、track 要素のトラック URL とします。

3. 非同期に残りの手順を実行しながら、テキスト・トラックの生成やテキスト・トラック・モードの変更のタスクが生じたら、それらを実行します。

4. Download: URL が空文字列ではなく、かつ、そのオリジンが、メディア要素の Document のオリジンと同じなのであれば、そのメディア要素の Document のオリジンから、force same-origin flag をセットして、URL をフェッチします。

   フェッチしているデータを処理するために、ネットワーキング・タスク・ソースにおけるフェッチ・アルゴリズムによってキューイングされたタスクは、それを入手できたら、そのリソースの Content Type メタデータを調べなければいけません。Content Type メタデータが入手できなかった、または、そのタイプがテキスト・トラック形式として認識できなかったら、そのリソースの形式は未サポートと見なさなければいけません（後述の通り、これによってロードは失敗になります）。タイプが入手でき、それがサポートしているテキスト・トラック形式を表していれば、そのリソースのデータは、受信時に、そのパーサーの出力に使われているテキスト・トラック・キュー・リストとともに、適切なパーサーに引き渡されなければいけません。

   フェッチ・アルゴリズムが何かしらの理由（ネットワーク・エラー、サーバーがエラー・コードを返した、クロス・オリジン・チェックが失敗した、など）で失敗した、または、URL が空文字列、または、この手順の始めで、条件によって決定されたのとは異なるオリジンを持つ、または、フェッチされたリソースがサポート対象の形式ではないなら、まずは、テキスト・トラック読取状態を failed to load に変更するタスクをキューイングします。それから、track 要素で error という名前のシンプルなイベントを発出します。そして、このタスクがキューイングされたら、後述の monitoring と書かれた手順へ移動します。

   フェッチ・アルゴリズムが失敗しなければ、それが完了するときに、まずは、テキスト・トラック読取状態を loadied に変更するタスクをキューイングします。それから、track 要素で load という名前のシンプルなイベントを発出します。そして、このタスクがキューイングされたら、後述の monitoring と書かれた手順へ移動します。

   フェッチ・アルゴリズムがアクティブとなっている間に、次のいずれかならば：

   • トラック URL が変更され、URL と同じでなくなり、テキスト・トラック・モードが hidden, showing, showing by default のいずれかにセットされた場合
   • テキスト・トラック・モードが hidden, showing, showing by default のいずれかに変更され、トラック URL が URL と同じでなくなった場合

   ... ユーザーエージェントは次の手順を実行しなければいけません：

   1. フェッチ・アルゴリズムを中止します。

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

   3. URL を新たなトラック URL とします。

   4. download と書かれた手順の最初へ戻ります。

   上記の状態の一つが発生するまで、ユーザーエージェントは、この手順でとどまっていなければいけません。

5. Monitoring: トラック URL が URL と同じでなくなるまで待機します。その時点で、テキスト・トラック・モードが hidden, showing, showing by default にセットされます。

6. テキスト・トラック読取状態が loading にセットされないようになるまで待機します。

7. 安定状態を待ちます。同期セクションは次の手順から構成されます。（同期セクションのこの手順は ⌛ でマーキングされています。）

8. ⌛ テキスト・トラック読取状態を loading にセットします。

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

10. download と書かれた手順へ飛びます。

メディア要素の textTracks 属性は、TextTrack タイプのオブジェクト用の配列ホスト・オブジェクトを返さなければいけません。これは固定長で読み取り専用です。この属性がアクセスされる都度、同じオブジェクトが返されなければいけません。 [WEBIDL]

この配列は、メディア要素のテキスト・トラック・リストにあるテキスト・トラックの TextTrack オブジェクトを、テキスト・トラック・リストと同じ順番で、含まなければいけません。

The kind attribute must return the text track kind of the text track that the TextTrack object represents.

The label attribute must return the text track label of the text track that the TextTrack object represents.

The language attribute must return the text track language of the text track that the TextTrack object represents.

The readyState attribute must return the numeric value corresponding to the text track readiness state of the text track that the TextTrack object represents, as defined by the following list:

NONE (numeric value 0)

The text track not loaded state.

LOADING (numeric value 1)

The text track loading state.

LOADED (numeric value 2)

The text track loaded state.

ERROR (numeric value 3)

The text track failed to load state.

The mode attribute, on getting, must return the numeric value corresponding to the text track mode of the text track that the TextTrack object represents, as defined by the following list:

OFF (numeric value 0)

The text track disabled mode.

HIDDEN (numeric value 1)

The text track hidden mode.

SHOWING (numeric value 2)

The text track showing and showing by default modes.

On setting, if the new value is not either 0, 1, or 2, the user agent must throw an INVALID_ACCESS_ERR exception. Otherwise, if the new value isn't equal to what the attribute would currently return, the new value must be processed as follows:

If the new value is 0

Set the text track mode of the text track that the TextTrack object represents to the text track disabled mode.

If the new value is 1

Set the text track mode of the text track that the TextTrack object represents to the text track hidden mode.

If the new value is 2

Set the text track mode of the text track that the TextTrack object represents to the text track showing mode.

If the mode had been showing by default, this will change it to showing, even though the value of mode would appear not to change.

If the text track mode of the text track that the TextTrack object represents is not the text track disabled mode, then the cues attribute must return a live TextTrackCueList object that represents the subset of the text track list of cues of the text track that the TextTrack object represents whose start times occur before the earliest possible position when the script started, in text track cue order. Otherwise, it must return null. When an object is returned, the same object must be returned each time.

The earliest possible position when the script started is whatever the earliest possible position was the last time the event loop reached step 1.

If the text track mode of the text track that the TextTrack object represents is not the text track disabled mode, then the activeCues attribute must return a live TextTrackCueList object that represents the subset of the text track list of cues of the text track that the TextTrack object represents whose active flag was set when the script started, in text track cue order. Otherwise, it must return null. When an object is returned, the same object must be returned each time.

A text track cue's active flag was set when the script started if its text track cue active flag was set the last time the event loop reached step 1.

The addTextTrack(kind, label, language) method of media elements, when invoked, must run the following steps:

1. If kind is not one of the following strings, then throw a SYNTAX_ERR exception and abort these steps:

   • subtitles
   • captions
   • descriptions
   • chapters
   • metadata

2. If the label argument was omitted, let label be the empty string.

3. If the language argument was omitted, let language be the empty string.

4. Create a new text track, and set its text track kind to kind, its text track label to label, its text track language to language, its text track readiness state to the text track loaded state, its text track mode to the text track hidden mode, and its text track list of cues to an empty list.

5. Add the new text track to the media element's list of text tracks.

The addCue(cue) method of MutableTextTrack objects, when invoked, must run the following steps:

1. If cue is null, then throw an INVALID_ACCESS_ERR exception and abort these steps.

2. If the given cue is already associated with a text track other than the method's MutableTextTrack object's text track, then throw an INVALID_STATE_ERR exception and abort these steps.

3. Associate cue with the method's MutableTextTrack object's text track, if it is not currently associated with a text track.

4. If the given cue is already listed in the method's MutableTextTrack object's text track's text track list of cues, then throw an INVALID_STATE_ERR exception.

5. Add cue to the method's MutableTextTrack object's text track's text track list of cues.

The removeCue(cue) method of MutableTextTrack objects, when invoked, must run the following steps:

1. If cue is null, then throw an INVALID_ACCESS_ERR exception and abort these steps.

2. If the given cue is not associated with the method's MutableTextTrack object's text track, then throw an INVALID_STATE_ERR exception.

3. If the given cue is not currently listed in the method's MutableTextTrack object's text track's text track list of cues, then throw a NOT_FOUND_ERR exception.

4. Remove cue from the method's MutableTextTrack object's text track's text track list of cues.

A TextTrackCueList object represents a dynamically updating list of text track cues in a given order.

The length attribute must return the number of cues in the list represented by the TextTrackCueList object.

The supported property indicies of a TextTrackCueList object at any instant are the numbers from zero to the number of cues in the list represented by the TextTrackCueList object minus one, if any. If there are no cues in the list, there are no supported property indicies.

To determine the value of an indexed property for a given index index, the user agent must return the indexth text track cue in the list represented by the TextTrackCueList object.

The getCueById(id) method, when called with an argument other than the empty string, must return the first text track cue in the list represented by the TextTrackCueList object whose text track cue identifier is id, if any, or null otherwise. If the argument is the empty string, then the method must return null.

The track attribute must return the TextTrack object of the text track with which the text track cue that the TextTrackCue object represents is associated, if any; or null otherwise.

The id attribute must return the text track cue identifier of the text track cue that the TextTrackCue object represents.

The startTime attribute must return the text track cue start time of the text track cue that the TextTrackCue object represents, in seconds.

The endTime attribute must return the text track cue end time of the text track cue that the TextTrackCue object represents, in seconds.

The pauseOnExit attribute must return true if the text track cue pause-on-exit flag of the text track cue that the TextTrackCue object represents is set; or false otherwise.

The direction attribute must return the text track cue writing direction of the text track cue that the TextTrackCue object represents.

The getCueAsSource() method must return the raw text track cue text.

The getCueAsHTML() method must convert the text track cue text to a DocumentFragment for the media element's Document, using the appropriate rules for doing so.

4.8.10.12.5 Event definitions

The following are the event handlers that must be supported, as IDL attributes, by all objects implementing the TextTrack interface:

The following are the event handlers that must be supported, as IDL attributes, by all objects implementing the TextTrackCue interface:

If the attribute is present, or if scripting is disabled for the media element, then the user agent should expose a user interface to the user. This user interface should include features to begin playback, pause playback, seek to an arbitrary position in the content (if the content supports arbitrary seeking), change the volume, change the display of closed captions or embedded sign-language tracks, select different audio tracks or turn on audio descriptions, and show the media content in manners more suitable to the user (e.g. full-screen video or in an independent resizable window). Other controls may also be made available.

If the media element has a current media controller, then the user agent should expose audio tracks from all the slaved media elements (although avoiding duplicates if the same media resource is being used several times). If a media resource's audio track exposed in this way has no known name, and it is the only audio track for a particular media element, the user agent should use the element's title attribute, if any, as the name (or as part of the name) of that track.

Even when the attribute is absent, however, user agents may provide controls to affect playback of the media resource (e.g. play, pause, seeking, and volume controls), but such features should not interfere with the page's normal rendering. For example, such features could be exposed in the media element's context menu.

Where possible (specifically, for starting, stopping, pausing, and unpausing playback, for seeking, for changing the rate of playback, for fast-forwarding or rewinding, for listing, enabling, and disabling text tracks, and for muting or changing the volume of the audio), user interface features exposed by the user agent must be implemented in terms of the DOM API described above, so that, e.g., all the same events fire.

When a media element has a current media controller, the user agent's user interface for pausing and unpausing playback, for seeking, for changing the rate of playback, for fast-forwarding or rewinding, and for muting or changing the volume of audio of the entire group must be implemented in terms of the MediaController API exposed on that current media controller.

The "play" function in the user agent's interface must set the playbackRate attribute to the value of the defaultPlaybackRate attribute before invoking the play() method. When a media element has a current media controller, the attributes and method with those names on that MediaController object must be used. Otherwise, the attributes and method with those names on the media element itself must be used.

Features such as fast-forward or rewind must be implemented by only changing the playbackRate attribute (and not the defaultPlaybackRate attribute). Again, when a media element has a current media controller, the attributes with those names on that MediaController object must be used; otherwise, the attributes with those names on the media element itself must be used.

When a media element has a current media controller, and all the slaved media elements of that MediaController are paused, the user agent should unpause all the slaved media elements when the user invokes a user agent interface control for beginning playback.

When a media element has a current media controller, seeking must be implemented in terms of the seek() method on that MediaController object. Otherwise, the user agent must directly seek to the requested position in the media element's media timeline.

When a media element has a current media controller, user agents may additionally provide the user with controls that directly manipulate an individual media element without affecting the MediaController, but such features are considered relatively advanced and unlikely to be useful to most users.

For the purposes of listing chapters in the media resource, only text tracks in the media element's list of text tracks showing or showing by default and whose text track kind is chapters should be used. Each cue in such a text track represents a chapter starting at the cue's start time. The name of the chapter is the text track cue text, interpreted literally.

The controls IDL attribute must reflect the content attribute of the same name.

The volume attribute must return the playback volume of any audio portions of the media element, in the range 0.0 (silent) to 1.0 (loudest). Initially, the volume must be 1.0, but user agents may remember the last set value across sessions, on a per-site basis or otherwise, so the volume may start at other values. On setting, if the new value is in the range 0.0 to 1.0 inclusive, the attribute must be set to the new value. If the new value is outside the range 0.0 to 1.0 inclusive, then, on setting, an INDEX_SIZE_ERR exception must be raised instead.

The muted attribute must return true if the audio channels are muted and false otherwise. Initially, the audio channels should not be muted (false), but user agents may remember the last set value across sessions, on a per-site basis or otherwise, so the muted state may start as muted (true). On setting, the attribute must be set to the new value.

Whenever either the muted or volume attributes are changed, the user agent must queue a task to fire a simple event named volumechange at the media element.

An element's effective media volume is determined as follows:

1. If the element's muted attribute is true, the element's effective media volume is zero. Abort these steps.

2. If the element has a current media controller and that MediaController object's media controller mute override is true, the element's effective media volume is zero. Abort these steps.

3. Let volume be the value of the element's volume attribute.

4. If the element has a current media controller, multiply volume by that MediaController object's media controller volume multiplier.

5. The element's effective media volume is volume, interpreted relative to the range 0.0 to 1.0, with 0.0 being silent, and 1.0 being the loudest setting, values in between increasing in loudness. The range need not be linear. The loudest setting may be lower than the system's loudest possible setting; for example the user could have set a maximum volume.

When a media element is created, if it has a muted attribute specified, the user agent must set the muted IDL attribute to true, overriding any user preference.

The defaultMuted IDL attribute must reflect the muted content attribute.

The length IDL attribute must return the number of ranges represented by the object.

The start(index) method must return the position of the start of the indexth range represented by the object, in seconds measured from the start of the timeline that the object covers.

The end(index) method must return the position of the end of the indexth range represented by the object, in seconds measured from the start of the timeline that the object covers.

These methods must raise INDEX_SIZE_ERR exceptions if called with an index argument greater than or equal to the number of ranges represented by the object.

When a TimeRanges object is said to be a normalized TimeRanges object, the ranges it represents must obey the following criteria:

• The start of a range must be greater than the end of all earlier ranges.
• The start of a range must be less than the end of that same range.

In other words, the ranges in such an object are ordered, don't overlap, aren't empty, and don't touch (adjacent ranges are folded into one bigger range).

The timelines used by the objects returned by the buffered, seekable and played IDL attributes of media elements must be that element's media timeline.

4.8.10.16 Security and privacy considerations

The main security and privacy implications of the video and audio elements come from the ability to embed media cross-origin. There are two directions that threats can flow: from hostile content to a victim page, and from a hostile page to victim content.

If a victim page embeds hostile content, the threat is that the content might contain scripted code that attempts to interact with the Document that embeds the content. To avoid this, user agents must ensure that there is no access from the content to the embedding page. In the case of media content that uses DOM concepts, the embedded content must be treated as if it was in its own unrelated top-level browsing context.

For instance, if an SVG animation was embedded in a video element, the user agent would not give it access to the DOM of the outer page. From the perspective of scripts in the SVG resource, the SVG file would appear to be in a lone top-level browsing context with no parent.

If a hostile page embeds victim content, the threat is that the embedding page could obtain information from the content that it would not otherwise have access to. The API does expose some information: the existence of the media, its type, its duration, its size, and the performance characteristics of its host. Such information is already potentially problematic, but in practice the same information can more or less be obtained using the img element, and so it has been deemed acceptable.

However, significantly more sensitive information could be obtained if the user agent further exposes metadata within the content such as subtitles or chapter titles. This version of the API does not expose such information. Future extensions to this API will likely reuse a mechanism such as CORS to check that the embedded content's site has opted in to exposing such information. [CORS]

An attacker could trick a user running within a corporate network into visiting a site that attempts to load a video from a previously leaked location on the corporation's intranet. If such a video included confidential plans for a new product, then being able to read the subtitles would present a confidentiality breach.

4.8.10.18 Best practices for implementors of media elements

This section is non-normative.

How accurately various aspects of the media element API are implemented is considered a quality-of-implementation issue.

For example, when implementing the buffered attribute, how precise an implementation reports the ranges that have been buffered depends on how carefully the user agent inspects the data. Since the API reports ranges as times, but the data is obtained in byte streams, a user agent receiving a variable-bit-rate stream might only be able to determine precise times by actually decoding all of the data. User agents aren't required to do this, however; they can instead return estimates (e.g. based on the average bit rate seen so far) which get revised as more information becomes available.

As a general rule, user agents are urged to be conservative rather than optimistic. For example, it would be bad to report that everything had been buffered when it had not.

Another quality-of-implementation issue would be playing a video backwards when the codec is designed only for forward playback (e.g. there aren't many key frames, and they are far apart, and the intervening frames only have deltas from the previous frame). User agents could do a poor job, e.g. only showing key frames; however, better implementations would do more work and thus do a better job, e.g. actually decoding parts of the video forwards, storing the complete frames, and then playing the frames backwards.

Similarly, while implementations are allowed to drop buffered data at any time (there is no requirement that a user agent keep all the media data obtained for the lifetime of the media element), it is again a quality of implementation issue: user agents with sufficient resources to keep all the data around are encouraged to do so, as this allows for a better user experience. For example, if the user is watching a live stream, a user agent could allow the user only to view the live video; however, a better user agent would buffer everything and allow the user to seek through the earlier material, pause it, play it forwards and backwards, etc.

When multiple tracks are synchronised with a MediaController, it is possible for scripts to add and remove media elements from the MediaController's list of slaved media elements, even while these tracks are playing. How smoothly the media plays back in such situations is another quality-of-implementation issue.

When a media element that is paused is removed from a document and not reinserted before the next time the event loop spins, implementations that are resource constrained are encouraged to take that opportunity to release all hardware resources (like video planes, networking resources, and data buffers) used by the media element. (User agents still have to keep track of the playback position and so forth, though, in case playback is later restarted.)