Multimedia and canvas elements in HTML5


The <canvas> element was originally developed by Apple® for use in Mac OS X
Dashboard widgets and in Safari, but was later adopted by Mozilla® and Opera® in
their Web browsers. The element has been standardized and included in the HTML5
specification, along with a series of 2D drawing APIs that can be used to create
shapes, text, transitions, and animations inside the element.
Many believe that the <canvas> element is one of the most important aspects of
HTML5 as it facilitates the production of graphs, interactive games, paint
applications, and other graphics on the fly without requiring external plug-ins such as
Adobe Flash.

The <canvas> element itself is quite basic, defining the width, height, and unique ID
for the object. The developer must then use a series of JavaScript APIs to actually
draw objects on the canvas, typically when the Web page has finished rendering.
These APIs allow the developer to draw shapes and lines; apply color, opacity, and
gradients; create text; transform canvas objects; and perform animation. The APIs
also allow the <canvas> to be interactive and respond to user input such as mouse
events and key events, facilitating the production of games and Web applications on
the canvas. You will see an example of the <canvas> element in action in the
sample HTML5/CSS3 Web site later in this tutorial.

<audio> and <video>

In recent years, the popularity of video sharing sites such as YouTube and content
delivery platforms like Hulu has seen a huge explosion in the use of the Web for
multimedia streaming. Unfortunately, the Web was not built with such content in
mind, and as a result, the provision of video and audio has by and large been
facilitated by the Flash Video (.flv) file format and the Adobe Flash platform.
HTML5, however, includes support for two new elements, <audio> and <video>,
which allow Web developers to include multimedia content without relying on the
user to have additional browser plug-ins installed. Several browsers, including
Mozilla Firefox, Apple Safari, and Google Chrome, have begun supporting these
new elements and providing standard browser playback controls, should the user
choose to use them. In addition, a set of standard JavaScript APIs has been
provided to allow developers to create their own playback controls, should they wish
to do so. A key advantage to native multimedia playback is that it theoretically
requires less CPU resources, which can lead to energy savings.
A key issue with these new multimedia elements, however, is the file formats
supported by each browser and the patent licensing issues that go along with the
various codecs that these files can be encoded with. Mozilla and Opera want to use
the open source Theora video container and codec, which does not require patent
licensing for the inclusion of the codecs in the Web browser. On the other hand,
Apple and Google are not happy with the quality of Theora, particularly for the
delivery of high definition (HD) content on the likes of YouTube. They prefer the
H.264 codec, typically contained in MP4, MOV, or MKV files.
The issue is not just with video however, as the same problems reside with audio
codecs. The MP3 and AAC formats are restricted by patents, whereas the Vorbis
format is not. The problem with Vorbis audio is that it is not in widespread use, as
portable media players and many media software applications do not support it.
There are many decisions to be made about HTML5 <video> and <audio> in the
near future, and it will be interesting to see what codecs and formats are facilitated in
the final recommendation. In the meantime, you can try to support all browsers by
making video available in a variety of formats and by providing Flash video as a
fallback. Let’s hope that a final decision is made, and that it is not left to browser
vendors to decide which formats to support, as that would essentially render these
new elements useless.
Again, you will see the <video> element in action later in this tutorial.

You Might Also Like