HTML5 Development Class: Media Events

By Curtis Dicken

http://www.htmlgoodies.com/html5/tutorials/HTML5-Development-Class-Media-Events-3883356.htm (Back to article)

Introduction

There has been much discussion surrounding the Media capabilities in HTML5. How will it impact Flash? Will we still need different media players like QuickTime and Windows Media Player? Why is HTML5 attempting to standardize media on the web?

While all of these are valid discussions that will be bantered about for the foreseeable future, this article will only provide you a foundation for the media events of HTML5 and a brief explanation of how media elements work. It’s up to you to decide what side of the different controversies you want to be on. Hopefully this article will give you the foundation for making informed opinions on HTML5 and its media capabilities.

About Media Events

Unlike other areas of HTML like mouse and keyboard events where there are both new HTML5 events and events ported from HTML4 to HTML5, media events in HTML5 are all new. All developers will have to learn about how media elements, attributes and events work with HTML5.

For new developers, once you have mastered the basic concepts of HTML elements, attributes and events you should be able to understand and begin using media with HTML5 fairly quickly. Seasoned developers should appreciate the straight-forward and intuitive design of HTML5’s media capabilities.

Now, before we get into the events you should first understand how a media element is structured. In this article I will use audio as my example but many of the events also apply to video, embed, img and object elements as well. However, it’s with the use of audio and video that these events will find their most frequent use.

Note: Currently audio and video file type support is extremely limited. The only file types currently included in the HTML5 specs at this time are ogg (audio), mp3 (audio), wav (audio), ogg (video) and mp4 (video). It should also be noted that browser implementation of the media capabilities is sketchy at best ranging to virtually no implementation in IE8 to almost complete implementation in Google Chrome 3.0.

Below is an example of what an audio element may look like. Make special note of the source element within the audio element and the controls attribute. With regard to the controls attribute, keep in mind some of the events listed in this article will never fire when the controls are not displayed to the user.

<audio controls="controls">
  <source src="HtmlGoodiesThemeSong.ogg" type="audio/ogg">
  <source src="HtmlGoodiesThemeSong.mp3" type="audio/mpeg">
Sorry, your browser does not support the audio element.
</audio>

The brief functional breakdown of the element above would be:

1. Try to play the .ogg audio file
2. If item 1 fails, try to play the .mp3 file
3. If item 2 fails, display the “browser does not support” message

If a browser does not understand the audio tag at all it should simply ignore the tag and display the “browser does not support” message. This “default message” concept is built into most of the new HTML5 elements for the purposes of backwards compatibility.

Media Events Explored

The first thing you will notice when starting to work with the media capabilities in HTML5 is that the same events apply to different types of standard media. Whether you are offering video or audio the events are the same. The second thing that you will notice is comprehensiveness of the events. The events cover all the most common points where a developer would want to perform an action.

• oncanplay – This event fires when a file is ready to start playing like when it has buffered enough to begin. Ideal for some alert text telling the user media is starting or ready to start to play.
• oncanplaythrough – This event is the cousin of oncanplay that fires when a file can be played all the way to the end without pausing for buffering. Useful for displaying messages that let the user know they can watch or listen to the file without interruption. It’s also useful for holding play until the file has fully buffered if that is important to your project.
• ondurationchange – This event fires when the length of media changes. For example, say you offer two different mixes of a song which are different lengths. When the user changes between files you may also need to change something like a custom progress bar.
• onemptied – This one fires when something bad happens and the file is suddenly unavailable like when the user’s ISP unexpectedly disconnects.
• onended – This event fires when the media end is reached. A useful event for messages like “thanks for listening”.
• onerror – As you would expect this event fires when an error occurs as the file is being loaded. Once the file is loaded other events like onemptied pretty much takes over handling errors and interruptions.
• onloadeddata – This fires when the media data is loaded. It follows the onloadedmetadata event below assuming no errors occur.
• onloadedmetadata – This event occurs when meta data like dimensions and duration are loaded. This is basically the second step of loading the file and is useful for projects where you may be doing something like a custom progress bar.
• onloadstart – This event would then be the first step in the initial loading process. It fires just as the file begins to load before anything is actually loaded. This is a good time to post a message that the file is loading.
• onpause – This event fires when the media is paused either by the user or programmatically. onplay – This event fires when the media is ready to start playing. This is the first of two events that fire when media is tasked to play.
• onplaying – This event fires when the media actually has started playing. This is the second of the two events that fire when media is tasked to play.
• onprogress – This event occurs when the browser is in the process of getting the media data. It’s an event that spans some of the other more precise events like onloadeddata.
• onratechange – This event fires each time the playback rate changes like when a user switches to a slow motion or fast forward mode.
• onreadystatechange – This event fires each time the ready state changes. The ready state basically tracks the state of the media data. For example, it can have a value of HAVE_METADATA which occurs when the duration of the media can be determined. If you are thinking this seems like an event that spans other events like onloadedmetadata you would be correct. Though the onreadystatechange attribute changing to HAVE_METADATA is not precisely the same as the onloadedmetadata event, the events could be used interchangeably in most circumstances. You can read more about readystate in the HTML5 Working Draft.
• onseeked – This event fires when the seeking attribute is set to false indicating that seeking has ended. Seeking is basically the act of moving the p-laying position forward and backward like when the user drags the progress bar pointer forward to fast forward to a particular point within the media.
• onseeking – This event fires when the seeking attribute is set to true indicating that seeking is active. This event will only fire if seeking lasts for more than just an instant.
• onstalled – This event fires when the browser is unable to fetch the media data for whatever reason. This is an event that is most helpful for handling connection interruptions that occur during buffering.
• onsuspend – This event is very similar to onstalled and fires when the fetching the media data is stopped before it is completely loaded. Sometimes this is due to connection issues while other times it might be user intervention. Whatever the case it allows the developer to prompt the user to try again or perform some other action.
• ontimeupdate – This event fires when the playing position has changed like when the user fast forwards to a different point in the media.
• onvolumechange – This event fires each time the volume is changed which includes setting the volume to mute.
• onwaiting – The event fires when the media has paused but is expected to resume like when the media pauses to buffer more data.

Conclusion

As you can see by the lengthy list above there are events at just about every point where a developer would want to perform some action. Most are intuitive and some overlap others. Even if you are violently opposed to the media functionality in HTML5, you must admit that it does make it very easy to add media to your web pages with very robust events for handling the user and browser interaction with the media.

Remember, though, implementation of the HTML5 specification is still very inconsistent among browsers so I would suggest testing out your scripts in Google Chrome as it has the most complete implementation so far. Happy coding!