HTML5 for web designers. Part 3: Multimedia

HTML5 for web designers

1. Brief history of markup language
2. HTML5 model
3. Multimedia
4. Forms 2.0
5. Semantics
6. HTML5 and modern conditions

In the history of the worldwide network, each new round of transition to a new level of development began with some technological innovation. When the img element was added to HTML, it radically changed the look of the web. Then the introduction of JavaScript made it more dynamic and interactive. Ajax appeared a little later, which opened up opportunities for creating full-fledged applications on the network.

Modern web standards are so advanced that now you can create almost anything, using only the capabilities of HTML, CSS and JavaScript. Almost anything.

There are still gaps in the specifications of these standards. So, if you want to create a page with text and images, you’ll be fine with HTML and CSS. But if you need to publish audio or video, there will inevitably have to turn to third-party technologies - Flash or Silverlight.
')
These technologies are “plug-ins”, such “plugs” that fill the “holes” in the network. They make relatively simple publishing of games, movies, and music online, but they are not open and are owned and controlled by private companies. Yes, the same Flash is a powerful tool, but its use is in some way similar to a deal with evil forces: we get new, inaccessible by other means, opportunities, but in return we lose some of our independence.

HTML5 is designed to fill this gap. At the moment, it is entering into direct competition with proprietary technologies, like Flash and Silverlight, and its main advantage in this fight is that it does not require plug-ins, since its multimedia capabilities are “sewn” into browsers.

Canvas

When the Mosaic browser had the opportunity to insert images into the pages, it gave the network a powerful push forward. But up to the present moment the pictures remain static. Yes, you can create animated gifs, update picture styles on the fly using JS, generate them on the server side. But in any case - as soon as the image is opened in the browser, its contents cannot be changed.

And here comes the canvas element, designed to create dynamically changeable images.

By itself, it is very simple. All that you specify in the tag parameters is the size of the canvas:

<canvas id="my-first-canvas" width="360" height="240"></canvas> 

As you can see, this tag is paired. But what you put inside it is intended only for browsers that do not support this element:

 <canvas id="my-first-canvas" width="360" height="240"> <p>No canvas support? Have an old-fashioned image instead:</p> <img src="puppy.jpg" alt="a cute puppy"> </canvas> 

Users of browsers without support
canvas will see a picture of a cute puppy.

All rendering work is assigned to JavaScript. First of all, you need to specify which element we are working with and in what context. The “context” in this case is an API, and today it is only one - two-dimensional (as you can see, there is room to grow):

 var canvas = document.getElementById('my-first-canvas'); var context = canvas.getContext('2d'); 

Now we can start drawing on this two-dimensional canvas of the canvas element using the API documented in the HTML5 specification . The set of tools here is similar to what you will find in any graphic editor like Illustrator: lines, fills, gradients, shadows, shapes, Bezier curves. The only difference is that instead of drawing with the mouse, you need to use the commands in JavaScript.

Drawing code

So the color of the lines is red:

 context.strokeStyle = '#990000'; 

Now everything you draw will have a red stroke. For example, the syntax for creating a rectangle looks like this:

 strokeRect ( left, top, width, height ) 

If you want to make this rectangle 50 pixels high, 100 wide, and position it 20 pixels from the left edge of the canvas element and 30 pixels from the top, you need to write the following:

 context.strokeRect(20,30,100,50); 

A rectangle drawn by the JS commands on the canvas .

Of course, this is an elementary example. The two-dimensional API includes many different methods: fillStyle, fillRect, lineWidth, shadowColor, and many more.

Theoretically, any image that can be created in the same Illustrator can also be created using the canvas element . In practice, however, it can be quite laborious and will give a huge amount of code at the output. On the other hand, this is not exactly what canvas was invented for.

And for what then? What is the use of it?

It's great that using JavaScript and canvas , you can create vector images on the fly, but if they are made any difficult, this work will not justify itself.

The meaning and main feature of the canvas is that its contents can be dynamically updated by drawing new elements in response to user actions. This ability to respond to events initiated by the visitor of the page makes it possible to create tools and games that would previously require the use of third-party technologies, such as Flash.

One of the first examples of the capabilities of the canvas -a project Bespin from Mozilla Labs - an application that is a simple text editor for coding, which works in a browser window.

Bespin web application created using the canvas element .

This is a very powerful thing. She is impressive. But also, it is a good example of what not to do with canvas .

Access is denied

Text editor, in its essence, is designed to work with text. Bespin successfully works with the text inside the canvas element , with only one reservation - it is no longer text. It’s just a collection of vector shapes that look like it.

Each page on the web can be described using the DOM - Document Object Model, “document object model”. A DOM can include many different “nodes,” the most important of which are elements, attributes, and text objects. These three types of “bricks” are enough to build almost any page you can imagine. In turn, the canvas element does not have a DOM — its contents cannot be divided into separate parts and presented as a tree of nodes.

Screen readers and other technologies for similar tasks are based on the ability to analyze the DOM to understand the structure and meaning of the document. No DOM - no access.

This “isolation” of canvas is a big problem for HTML5. Fortunately, some smart people are working on its solutions . Since this moment is rather serious, I don’t want to rush the process, but at the same time I don’t want it to slow down the development of the rest of the specification.

Smart canvas

Based on the above, we can assume that at the moment web designers do not make sense to use canvas in their projects. This is not true.

When I use javascript on my site, it serves exclusively an additional improvement. Those visitors who have it disabled, will not be deprived of access to information, except perhaps only certain minor amenities. Such a multi-level approach called “Unobtrusive JavaScript” can also be applied to the canvas . Instead of creating new content, it will be used to better present the existing one.

Suppose you have a table with some data. You want to illustrate the trend in them with a graph. If the data is static - you can simply generate a graph-image using the Google Chart API, for example. But if the data can be changed along the way, it would be great to create a graph that is drawn every time on a new one with the changes. Canvas is perfect here - you can use JavaScript to extract the contents of the table element and create a mathematically calculated illustration on its basis.

The smart guys from the Filament Group even developed a jQuery plugin for this, by the way.

Examples of graphs generated using canvas

There is another option. In fact, the canvas element is not the only API for generating dynamic images. SVG - Scalable Vector Graphics, scalable vector graphics - XML ​​format that can be used to describe the same shapes as the canvas . And based on the essence of XML as such, the contents of the SVG are theoretically “understandable” for screen-reading devices.

But in practice, SVG did not make an exceptional impression on developers, unlike canvas , which, although it appeared only recently, is already widely supported by accessible browsers. Its capabilities are even realizable in IE using an additional JavaScript library .

Given the WHATWG slogans about “paving the rubble” and “not reinventing the bike”, it may seem strange that they chose to include the canvas in HTML5 when there is already a similar SVG technology. As it often happens, the HTML5 specification actually only documents a lot of what is already supported by browsers. Canvas was not designed for HTML5 - it first appeared in Safari and was created by Apple. When the developers of other browsers saw this idea, they liked it and was copied.

This may seem a bit haphazard and disorganized, but the fact is that many of our standards are born. Take at least the underlying Ajax XMLHttpRequest object, first implemented at the end of the last century in Microsoft Internet Explorer 5.

In the world of browsers, where the fittest survives, canvas is currently gaining strength and popularity. As soon as it becomes more “open” to access from the outside, its positions will be securely fixed.

Audio

My first site was the page of a musical group in which I participated, and I wanted its visitors to directly listen to our songs from there. The decision to realize this opportunity encouraged me to study the available formats and players. QuickTime, Windows Media Player, Real Audio - I spent too much time considering how popular and cross-platform each of them are.

In those transitional years, MP3 eventually became the winner for the title of the most popular music format. But in order to allow visitors to simply listen to the sound file from the page, the use of third-party technologies is still required. Here the winner is clearly Flash.

And now HTML5 plans to strip him of this title.

Inserting an audio file into an HTML5 page looks simple:

 <audio src="witchitalineman.mp3"> </audio> 

But it is too easy. You will probably need a bit more options.

Suppose there is such an evil reptile in the world who hates the global network and all its users. Such a person does not care that it is very rude and just silly to insert an audio file on a page that starts playing automatically. The autoplay parameter will please him.

 <audio src="witchitalineman.mp3" autoplay> </audio> 

If I see that you use autoplay for such purposes, do not expect mercy from me at the meeting.

Note that this parameter does not matter; in the sense of - used by itself. Pieces of this kind are called Boolean parameters , in honor of the greatest mathematician George Bul. All computer systems are based on the binary logic developed by him, where the basic values ​​of variables are always either zero or one, true or false.

However, one should not confuse boolean parameters with boolean values . It is excuse to think that a boolean parameter must be true or false , but it is not. The very essence of its existence is already boolean, that is, binary, - it either is ( true ) or it does not exist at all ( false ). Even if you add any value to such an attribute, it will not have any effect: autoplay = “false” or autoplay = “no thanks” - the same as autoplay .

If you only use XHTML syntax, then autoplay = “autoplay” for you. Approved by the International Department of Redundancy.

When auto-playing an audio file doesn’t seem vile enough, you can also add another boolean parameter - loop , which loops the sound and makes the torture infinite.

 <audio src="witchitalineman.mp3" autoplay loop> </audio> 

The combination of these parameters will further reduce your chances of staying alive when you meet me.

Everything's under control

But let's move on to how to use the audio element for good. It is logical to add the ability to control playback, and this can be easily done using the Boolean parameter controls .

 <audio src="witchitalineman.mp3" controls> </audio> 

It will turn on the display of standard browser controls for the play-pause button and volume control.

controls displays the native browser-based playback control interface.

If you do not like the style of controls, set by the browser, you can arrange them to your liking. Using JavaScript, you can access the Audio API, which provides access to the play and pause methods and the volume property. Here is a rough example of such customization using button elements and unseemly event handlers inside tags:

 <audio id="player" src="witchitalineman.mp3"> </audio> <div> <button onclick="document.getElementById('player').play()"> Play </button> <button onclick="document.getElementById('player').pause()"> Pause </button> <button onclick="document.getElementById('player').volume += 0.1"> Volume Up </button> <button onclick="document.getElementById('player').volume -= 0.1"> Volume Down </button> </div> 

Custom controls made with button elements.

Buffering

For a while, the HTML5 specification included another boolean parameter - autobuffer . This one was much more polite and more useful than a nasty autoplay - he pointed out to the browser that, although the audio file should not immediately start playing, it should be reloaded in the background, because sooner or later it will be launched anyway.

This would be a very useful option, but, unfortunately, Safari went further. This browser has started preloading the audio file, ignoring the autobuffer . And since - you remember - autobuffer is a boolean parameter, you can’t use it to prevent rebooting: autobuffer = “false” is the same as autobuffer = “true” , as any value ( bug description ).

So now the autobuffer has been replaced by the preload parameter. It is not boolean; it takes one of the following three values: none , auto, and metadata . Using preload = “none” , we explicitly tell the browser that there is no need to preload this file.

 <audio src="witchitalineman.mp3" controls preload="none"> </audio> 

If you have only one audio element on the page, preload = “auto” is fully justified and logical. But do not do this if there are several of them, in order not to offend visitors with not the fastest and / or unlimited Internet.

I will sing "curb", you will sing "curb"

It seems that the audio element seems to be perfect in everything. There is clearly a trick here. Unfortunately, this is true, but not with the specification of the element as such, but with audio formats.

Although MP3 is currently the most common, this format is not open. For the opportunity to work with him is required to pay a certain amount of patent holders. For large corporations like Apple or Adobe, this is clearly not a problem, unlike smaller companies and open-source groups. That's why MP3 works great in Safari, but it doesn't play in Firefox.

There are, of course, other formats. For example, the Vorbis codec — usually outputting .ogg files — is not burdened with any patents. This one works in Firefox, but, in turn, is not supported by Safari.

Fortunately, there is no need to make a cruel choice in favor of only one particular format. Instead of the src parameter in the <audio> tag , you can use several source elements enclosed in it for different files:

 <audio controls> <source src="witchitalineman.ogg"> <source src="witchitalineman.mp3"> </audio> 

A browser with Ogg Vorbis support will pick up the first file and will not go further. A browser that can play MP3s but does not understand Ogg will skip the first file and download the second one.

You can help them choose by specifying the mime-type for each file:

 <audio controls> <source src="witchitalineman.ogg" type="audio/ogg"> <source src="witchitalineman.mp3" type="audio/mpeg"> </audio> 

The source element is a single, non-container element, so if you use the XHTML syntax, you need to close the tag with a slash: <source /> .

For the not so gifted

The ability to specify multiple source sources is great, but there are browsers that do not support the audio element at all. Well, you understand what I mean.

Internet Explorer and his ilk require that audio files be fed from a spoon, through good old Flash. The audio element model supports this: everything inside the tag and not a source element will be served to browsers that do not support audio — as an object element in this case:

 <audio controls> <source src="witchitalineman.ogg" type="audio/ogg"> <source src="witchitalineman.mp3" type="audio/mpeg"> <object type="application/x-shockwave-flash" data="player.swf?soundFile=witchitalineman.mp3"> <param name="movie" value="player.swf?soundFile=witchitalineman.mp3"> </object> </audio> 

You can even go further. The object element in itself also allows the insertion of alternative content - for those with a browser it’s completely bad, you can make a standard link:

 <audio controls> <source src="witchitalineman.ogg" type="audio/ogg"> <source src="witchitalineman.mp3" type="audio/mpeg"> <object type="application/x-shockwave-flash" data="player.swf?soundFile=witchitalineman.mp3"> <param name="movie" value="player.swf?soundFile=witchitalineman.mp3"> <a href="witchitalineman.mp3">Download the song</a> </object> </audio> 

Thus, the priorities are in the following order:

1. Sound in Ogg Vorbis format via audio element
2. MP3 audio through the audio element
3. Flash Sound
4. Link for downloading the file directly

Content availability

The audio element model is very useful for specifying alternative methods for presenting its content. But if, for example, you want to provide a text version of a song for those who cannot listen to it, do not do the following:

 <audio controls> <source src="witchitalineman.ogg" type="audio/ogg"> <source src="witchitalineman.mp3" type="audio/mpeg"> <p>I am a lineman for the county...</p> </audio> 

In this case, the contents of <p> will only appear if the visitor’s browser does not support the audio element. This will not be useful for a deaf user with a modern browser. In addition, the lyrics of the song can be useful to everyone else - why then hide it?

 <audio controls> <source src="witchitalineman.ogg" type="audio/ogg"> <source src="witchitalineman.mp3" type="audio/mpeg"> </audio> <p>I am a lineman for the county...</p> 

Video

If the built-in audio support is impressive, then the prospects for the ability to play video so generally cause wild delight. With the proliferation of broadband connectivity, video has become very popular on the Internet. At the moment, Flash is mainly used to display it - HTML5 plans to change it.

The video element works in a similar way with audio : the same parameters are autoplay , loop , preload ; the same system with the src attribute or several nested source elements; in the same way, you can add a standard control interface using controls , or make your own.

The main difference between audio and video is that the latter usually takes up a bit more space on the page, so you probably want to specify the exact dimensions:

 <video src="movie.mp4" controls width="360" height="240"> </video> 

What else you can do is add a thumbnail as an image using the poster parameter:

 <video src="movie.mp4" controls width="360" height="240" poster="placeholder.jpg"> </video> 

The preview is displayed before the video starts playing.

Not the most pleasant news is that the struggle of formats in the video environment is even tougher than among audio. The main players are: MP4 (burdened with the patent) and Theora Video (free and clean). But you already know how such problems are solved:

 <video controls width="360" height="240" poster="placeholder.jpg"> <source src="movie.ogv" type="video/ogg"> <source src="movie.mp4" type="video/mp4"> <object type="application/x-shockwave-flash" width="360" height="240" data="player.swf?file=movie.mp4"> <param name="movie" value="player.swf?file=movie.mp4"> <a href="movie.mp4">Download the movie</a> </object> </video> 

All that remains for us to do is to wait for the browser developers to agree on the same standard, so that everything will start working as intended by the developers of the specification - without unnecessary cloning of files in different formats.

Fashionable, stylish, native

The ability to embed video using standard markup language tools can be the most awesome innovation after creating an img element. Even big players like Google are not shy about showing enthusiasm for this. Here, for example, what they conceived for a new YouTube: www.youtube.com/html5

The main problem in using plugins for working with multimedia has always been their isolation from the rest of the document. Now, when all these elements are part of a common system, they are easily accessible to scripts and styles.

The video element meets CSS3. Try to do this with a plugin.

Audio and video support as part of HTML5 received our approval and delight. But we know that the world wide web is not so much a presentation medium, it is also interactive. And the oldest, but consistently powerful, tool for achieving interactivity on web pages has always been form. In the next chapter, we will look at what new features HTML5 offers for them.