しかし、メディアというものには本質的に時系列の処理が伴います。オーディオ／ビデオファイルやネットワーク接続について読み込みとキャッシュの両方が必要になれば、それだけで大変な作業が生じます。その難しさは、時間的な処理を必要としないリソースのほとんどを扱う場合には見られないものです。こうした理由から、Web上でのビデオやオーディオの処理を何らかの方法で制御したければ、非同期処理によって、メディア提供側のWebサイトからクライアントに返されるさまざまなイベントを処理する必要があります。表4に、すべてのイベントの一覧と、それらがディスパッチされるタイミングを示します（HTML 5に関するドキュメントから引用）。
表4 メディアユーザーインターフェースのイベント
| イベント名 | インターフェース | ディスパッチのタイミング | 前提条件 |
| loadstart | Event | リソース選択アルゴリズムの一環として、ユーザーエージェントがメディアデータの検索を開始 | networkStateがNETWORK_LOADINGに等しい |
| progress | Event | ユーザーエージェントがメディアデータのフェッチを実行 | networkStateがNETWORK_LOADINGに等しい |
| suspend | Event | ユーザーエージェントが意図的にメディアデータのフェッチを現在行っていないが、メディアリソース全体のダウンロードが済んでいるわけでもない | networkStateがNETWORK_IDLEに等しい |
| abort | Event | ダウンロードの完了前にユーザーエージェントがメディアデータのフェッチを停止したが、この停止はエラーによるものではない | errorがMEDIA_ERR_ABORTEDというコードを持つオブジェクトである。networkStateがNETWORK_EMPTYとNETWORK_IDLEのどちらか（ダウンロード中止のタイミングに依存）に等しい |
| error | Event | メディアデータのフェッチ実行中にエラーが発生 | errorがMEDIA_ERR_NETWORK以上のコードを持つオブジェクトである。networkStateがNETWORK_EMPTYとNETWORK_IDLEのどちらかに等しい |
| emptied | Event | メディア要素のnetworkStateがNETWORK_EMPTYの状態になった（レポート対象となる読み込み中に致命的なエラーが発生したか、リソース選択アルゴリズムがすでに実行されている状態でload()メソッドが実行されたことが原因。後者の場合、load()の呼び出しに同期してイベントが発生する） | networkStateがNETWORK_EMPTYであり、すべてのIDL属性が初期状態にある |
| stalled | Event | ユーザーエージェントがメディアデータのフェッチを試みたが、データがまだ用意されていない | networkStateがNETWORK_LOADINGである |
| play | Event | 再生が開始された。play()メソッドからの復帰後に発生する | pausedがfalseになった |
| pause | Event | 再生が一時停止された。pauseメソッドからの復帰後に発生する | pausedがtrueになった |
| loadedmetadata | Event | ユーザーエージェントがメディアリソースの長さと寸法を判定した | readyStateが初めてHAVE_METADATA以上の値になった |
| loadeddata | Event | ユーザーエージェントがメディアデータのレンダリングを現在の再生位置で初めて行えるようになった | readyStateが増加によって初めてHAVE_CURRENT_DATA以上の値になった |
| waiting | Event | 次のフレームが利用不可のため再生を停止したが、ユーザーエージェントはそのフレームがやがて利用可能になると想定している | readyStateがHAVE_CURRENT_DATA以下の値になり、かつpausedがfalseである。seekingがtrueであるか、バッファリングされた範囲のいずれにも現在の再生位置が含まれていない。pausedがfalseになることなく、他の2つの理由（再生が終了したか、再生がエラーによって停止した）によって再生が停止する可能性がある |
| playing | Event | 再生が開始された | readyStateがHAVE_FUTURE_DATA以上の値になったか、pausedがfalseであるか、seekingがfalseであるか、現在の再生位置がバッファリングされた範囲のいずれかに含まれる |
| canplay | Event | ユーザーエージェントはメディアデータの再生を再開できるが、今すぐに再生を開始すればコンテンツのさらなるバッファリングのために停止せずには現在の再生速度でメディアリソースを最後までレンダリングできないと予測している | readyStateが増加によってHAVE_FUTURE_DATA以上の値になった |
| canplaythrough | Event | ユーザーエージェントは、今すぐに再生を開始しても、コンテンツのさらなるバッファリングのために停止することなくメディアリソースを現在の再生速度で最後までレンダリングできると予測している | readyStateがHAVE_ENOUGH_DATAになった |
| seeking | Event | IDL属性であるseekingがtrueに変化し、ユーザーエージェントがこのイベントを発生させるのに十分な時間がシーク操作にかかっている | |
| seeked | Event | IDL属性のseekingがfalseに変化した | |
| timeupdate | Event | 現在の再生位置の変化が、通常の再生に伴って、あるいは特に興味深い形（不連続的な変化など）で起こった | |
| ended | Event | メディアリソースの終端に達したので再生が停止した | currentTimeがメディアリソースの終端に等しく、endedがtrueである |
| ratechange | Event | defaultPlaybackRate属性とplaybackRate属性のどちらかが更新された | |
| durationchange | Event | duration属性が更新された | |
| volumechange | Event | volume属性とmuted属性のどちらかが変化した。関連する属性セッターからの復帰後に発生する |
表4に示したイベントのなかで特に便利なものとして、canplayイベントとcanplaythroughイベントが挙げられます。canplayイベントは、すべてのデータの読み込みが終わっていなくても、ビデオプレーヤーが実際にコンテンツのレンダリングを意味のある形で開始できるだけのデータが読み込まれた時点で発生します。一方のcanplaythroughイベントは基本的に、ブラウザのバッファへのデータ読み込みが完全に済み、途中で再生を一時停止して残りのコンテンツを取得しなくてもビデオを最後まで再生できるようになった時点で発生します。
