A Guide to HTML

Including Media

Very early versions of HTML only supported marking up text. Nearly everyone found this to be horribly limiting, so HTML tags were soon created that allowed designers to link to media resources in an HTML document.

If you’re displaying media files on your page, it is common courtesy to serve them from your own website. Serving media files directly from another website is called hotlinking, and it wastes the other website’s bandwidth. Many websites have set up their server software to prevent hotlinking.

On the web server, media files are usually stored in their own folder. This folder will probably have sub-folders for different kinds of media, like images or audio. FTP software needs to transfer media files using binary mode, unlike HTML, JavaScript, or CSS, which all use text mode. Putting the media files in separate folders makes this convenient. Additionally, it is possible to set up server software to prevent hotlinking, by blocking access to media folders from HTTP requests made by other websites.

Inline frame. This is an area of one HTML page that includes the entire contents of another HTML page.

An inline frame is commonly used to embed media from a third-party website (like YouTube, Bandcamp, or Scribd). In most cases, the third-party website itself will provide the HTML code to embed the media (including the <iframe> tag). There are several reasons why you would do this:

  • The third-party site does not allow direct access to the media file itself. This is likely because they want to retain the commercial branding around the media, or it could be for bandwidth reasons.
  • The thrid-party HTML page is designed to be a “widget” that combines different things with the media. For example, a music site may have a page designed for embedding a song that could include album art, lyrics, a download link, etc.
  • The third-party HTML page has a mechanism for dealing with different internet speeds or user agents. For example, if a user has a slow internet connection, the page could detect this and deliver lower-quality video. Or, if the media is displayed using HTML5 tags, and the user agent doesn’t support HTML5, the page could fall back to using Adobe Flash.

Of course, the contents of an <iframe> don’t have to be media. Twitter feeds, for example, are often displayed using an <iframe>. And, of course, a very common use of an <iframe> is to embed advertising.

There are a couple of things that you should keep in mind. First, the contents of <iframe> elements don’t take part in the embedding page’s history. Returning to the page (e.g. from a bookmark) will load the same frame as it would if the user first encountered the page. Second, you should always be aware of security concerns. If you’re embedding a page from a thrid party, make sure that the page does not partake in any malicious behavior.

Not all user agents support the <iframe> element. For example, it is almost never displayed in an email client, for security reasons. The content of the <iframe> tag should be used to display text for these user agents. A good choice of text would be a hyperlink to the HTML document, but it could be anything you want (except another <iframe>, of course).

One other thing. The content of an inline frame does not have to be HTML; it could be anything that the browser can display (like an image file). This is a bad use of the <iframe> tag; other tags are better suited for this purpose.


The source of the inline frame. This is a URL to the HTML page that will be displayed in the <iframe>. This may be a relative URL, but more than likely, it will be a fully-qualified URL to a page at another website.
The height of the inline frame, in pixels. (HTML 4.01 also allowed other units, or a percentage, but this is deprecated in HTML5.)

An HTML element’s height would normally be in the province of CSS, but framed HTML pages are often designed to be “widgets” with specific dimensions. This depends entirely on the content of the <iframe>, so is often specified in this attribute.

The width of the inline frame, in pixels. Again, this would normally be specified by CSS, but not in this case.
sandbox (HTML5 only)
Security has always been an issue when embedding someone else’s HTML page into your own. HTML5 addressed this by creating the standbox attribute. This attribute specifies that the embedded HTML page should act like it’s in a sandbox: an environment that is isolated from the rest of the system. Errors or malicious behavior in the sandbox won’t affect the rest of the system, adding a great deal of security.

In this context, a sandboxed page won’t be able to run JavaScript, open pop-up windows, submit forms, and so forth. If you want to allow the embedded HTML page to do these things, then you need to explicitly add these permissions back. This is done through the value of the sandbox attribute: you specify a space-separated list of allowed actions. Those actions may be any of:

Allows the embedded HTML page to submit forms. If they don’t have this permission, forms will still be displayed, just not submitted.
Allows the embedded HTML page to use the pointer lock API. This API allows the page to capture the user’s pointer (mouse) movements, even outside the boundaries of a page, and to do things like hide the cursor. It is commonly used in browser-based video games.
Allows the embedded HTML page to open popup windows, either through JavaScript, or with the <a> tag’s target="_blank" attribute.
If included, the embedded HTML file will use its normal origin (protocol, hostname, and port number). If not included, the embedded HTML file will be treated as if it came from a unique origin. Among other things, this means that origin-aware storage mechanisms (like cookies) will fail.
Allows the embedded HTML page to run scripts (JavaScript). However, even if this value is specified, the page will not be allowed to create pop-up windows. You must use the allow-popups value for that.
Allows the embedded HTML page to change the URL of the parent page in the browser.

If you don’t want the embedded HTML page to do any of these things, simply put an empty string in the attribute: sandbox=""

seamless (HTML5 only, discouraged)
This attribute specifies that the frame should blend seamlessly with the surrounding HTML page, without any borders or scroll bars. It is discouraged because, as of this writing, not a single browser supports it. The same effect can be achieved using CSS, so use that instead.
srcdoc (HTML5 only)
The HTML source of the embedded document. This is not a URL; it is actual HTML code. If a browser supports the srcdoc attribute, it will display that HTML code as the embedded page, ignoring the src attribute. If not, it will simply display the page from the URL in the src attribute.

Of course, nobody wants to put the code for an entire HTML page into an attribute string, so this will almost certainly be machine-generated (by either JavaScript or server-side code). This allows the <iframe> to display dynamically generated content, using the src attribute to specify a fallback.

This attribute is not supported in Internet Explorer.

There were a number of other attributes in the HTML 4.01 specification, but they have been deprecated in HTML5. (Most were presentational anyway.) Also, certain browsers (notably Firefox) had their own browser-specific attributes, but most of these are also deprecated. I won’t even list these attributes.

<img />
An image. This could be a picture, chart, logo, or what have you. This is an empty tag, and must be properly terminated.

In most situations, this tag should not be used for icons (e.g. the magnifying glass image next to a search form), or for decorative images common to all pages in the site. With these kinds of images, you should use CSS to set the background image of the relevant elements. Instead, the <img> tag should be used for images that stand alone as distinct content: photos, illustrations, thumbnails in an image gallery, etc.

Common Formats:

JPEG (Joint Photographic Experts Group)
This format is good for images that have lots of colors that blend into each other, like photographs. Most digital cameras save images in this format.
PNG (Portable Network Graphics)
This format was created as an improved, non-patented replacement for the GIF format (see below). It is a good format to use for images that have large areas of one solid color, like logos or graphs. The PNG format supports alpha transparency, where each pixel can have its own degree of transparency. However, versions of Internet Explorer prior to IE7 did not support alpha transparency. Also, PNG’s do not support animation, unlike GIF’s. (Though there are unofficial extensions to the standard which do support animation, they are not recognized by most browsers.)
GIF (Graphics Interchange Format)
This format is also good for images with large areas of one solid color. Unlike a PNG, it is limited to 8-bit color depth. It also supports transparency, but only one pixel color can be designated as transparent; this can result in “crufting” around the transparent part if the edges do not match the page color. GIF’s also support animation, and this is one area where GIF’s are still widely used.

The compression algorithm used by the GIF format is LZW (Lempel–Ziv–Welch), which is also used in other image formats. This algorithm was covered by patents in the U.S. until 2003, and in other parts of the world until 2004. The patents were owned by Unisys, and in the late 1990’s, they announced their intention to charge licensing fees for the use of GIF’s on commercial websites. This move was widely condemned, and spurred the development of the PNG format.

How you pronounce “GIF” is the subject of bizarrely acrimonious debate. Many people pronounce it “jif” (like the peanut butter), but many others pronounce it “ghif” (like the “g” in the word “graphics”). I personally pronounce it “jif,” and so does the creator of the format, but I think both pronunciations should be acceptable. Or, just pronounce it according to how much you like arguing with the other guy.

There are other kinds of image formats, of course, but they aren’t supported by all browsers. Additionally, the above formats have the advantage of variable compression levels, so a tradeoff can be made between image quality and file size. For example, a thumbnail may be highly compressed, but a full-size image may have minimal compression.


The source of the image. This can be either a relative path or a fully-qualified URL (to your own site, if you don’t want to hotlink).
Alternative text. This attribute is used to identify the image, for user agents that don’t display them (like screen readers or web crawlers).

It should not be used like the global title attribute, which provides additional information about an image, like a short description. For example, a picture of Tim Berners-Lee might have alt="Tim Berners-Lee", but title="Tim Berners-Lee, creator of HTML and inventor of the World Wide Web". The alt text (unlike the title text) will not be used as a tooltip in any browser except Internet Explorer.

height (discouraged)
The height of the image, in pixels. This allows the user agent to resize the image. It is generally a bad idea to do this, as smaller images look terrible when enlarged, and large images will use more bandwidth than necessary. Instead, you should actually create a differently-sized image (in Photoshop, Gimp, or whatever), and link to that image.
width (discouraged)
The width of the image, in pixels. It is discouraged for the same reason height is discouraged.
usemap (uncommon)
This is a fragment identifier for the ID (or name) of an image map to associate with this image. So, if your image map has the ID of mymap, the value of this attribute would be "#mymap". See below for details.

To add a caption to an image, put the <img> tag inside a <figure> element, and use the <figcaption> tag. In this case, the image’s description are in both the <figcaption> content and the <img> tag’s title attribute. It would probably be a good idea to put the same description in both, though this is not always possible.

<map> (uncommon)
Defines an image map. This is a large image, divided into independent regions (areas) which can be clicked on. They are not widely used, because there are not many cases where image maps are a good idea. However, if you’re making an interactive map (like a clickable map of the United States), then you’ll probably want an image map.

The HTML specification requires the name attribute. This attribute was deprecated in XHTML 1.0, so you should use the id attribute instead, but it is still required. To associate an image map with its actual image, use this ID in a fragment identifier, and use the fragment identifier as the value of the usemap attribute of an <img> tag. For example, to associate an image map with an ID of mymap with an image called myimage.jpg, then you would use this <img> tag:

<img src="myimage.jpg" usemap="#mymap" />

The <map> element can only have <area> elements as children; the <img> tag should go outside the <map> tag.

You can also use an image map with the <object> tag (see below), but I’ve never seen anyone do this.

<area> (uncommon)
Defines one area of an image map. Each area is a clickable link to another web page, or section of a page (though it may also be targeted by JavaScript).

Note: Since the area is essentially an image link, it shares most of these attributes with the <a> and <img> tags. I already covered them, so my descriptions here will be brief.

Alternate text for the area. This is required if the href attribute is present, and forbidden if it is not.
Specifies the coordinates for the area. This is a comma-separated list of coordinate pixel values. The origin of these coordinates is the top left of the image map. The number and type of coordinates depend upon the shape attribute (see below).
Hyperlink reference. This can be a fully-qualified URL, a relative path, or a URL fragment. If this attribute is present, the alt attribute must also be specified.
The shape of the region. This can have the following values:

    A circle. The coords attribute should be of the format x,y,r, where x and y are the coordinates of the center of the circle, and r is the radius.
    Default state. You use this attribute to define the link for the entire image map, if the user clicks outside any area defined by another <area> tag.
    A multi-sided polygon. The coords attribute should be a set of at least three x,y pairs, where each pair is the coordinates of one point of the polygon.
    A rectangle. The coords attribute should be a comma-separated pair of x,y coordinates (so four values in total), specifying the top-left and bottom-right points of the rectangle (in that order).
The target of the link. Must be _blank, _parent, _self, _top, or an <iframe> ID.
Embeds an object into the HTML page. This can be any type of resource at all (like a PDF, Java applet, or even an image or HTML file), but the most popular type of object is an Adobe Flash file. In most cases, the object will require a (proprietary) browser plug-in to display properly. One of the reasons HTML5 standardized its media tags was to get rid of proprietary plugins, so you should use one of those instead. Of course, not old browsers don’t support HTML5, and if you want to support those browsers you won’t have another option.

Parameters are sent to the object using <param> elements; see below. These must be child elements of the <object> element, but they do not have to be the only elements.

Not all users will have installed the plug-in required to view the object. In these cases, the browser will instead display the HTML between the opening and closing tags (ignoring all <param> elements). This can be whatever you like, but it is standard practice to tell users why they can’t view the object, and provide a link to download the required plug-in.


The URL of the object. This can be a fully-qualified URL, or a relative path. If this attribute is not specified, then the type attribute is required.
The MIME type of the object. This can be any valid MIME type; for example, an Adobe Flash .swf file would have the MIME type "application/x-shockwave-flash". If this attribute is not specified, then the data attribute is required.
The height of the object, in pixels. As with an <iframe>, the height is dependent upon the object, so this cannot be set with CSS.
The width of the object, in pixels.
typemustmatch (HTML5 only)
If this attribute is present, then the MIME type sent by the server in the HTTP header must match the value the type attribute. Otherwise, the object will not be viewed. This was added in the HTML5 specification as a security feature.

This is a Boolean attribute, so its value must be typemustmatch. It should not be present unless both the data and type attributes are specified.

form (HTML5 only)
A form ID. This will associate the object with a specific form.
usemap (discouraged)
Specifies an image map to use with this object. Image maps themselves are rare, and I’ve never seen any website that uses one with an <object> element. Just as well, since this attribute is not supported in any browser except Internet Explorer and Firefox.
Provides a parameter for an object. A <param> element must be a child of an <object> element. The <param> attributes will be passed, as a name/value pair, to the resource identified by the data attribute of the parent <object>. The parameter names and values are determined by the type attribute of the <object> tag; a Flash file will take different parameters than a Java applet.

It is an empty element, and must be properly terminated.


The name of the parameter. (This is different from the global name attribute; it is not deprecated, is not an ID, and the id attribute cannot be used instead.)
The value of the parameter.

HTML5 Media

As you could probably tell, multimedia in HTML 4.01 was a problem. With the exception of image tags and inline frames, including media in an HTML page involved heavy use of the <object> tag. This usually meant that users must install a plug-in to handle anything related to audio or video. The reliance on plug-ins caused a host of problems. They were often not available for open-source browsers, and sometimes not even for open-source operating systems like Linux. Mobile phone support was virtually non-existent. In a few cases, the plug-ins had security vulnerabilities. And because they were proprietary, there was little that could be done about any of this; the source code wasn’t available, and reverse engineering was usually prohibited by the end-user licensing agreement. The most widely used of these plug-ins, hence the most notorious, was Adobe Flash.

The HTML5 standard attempted to do away with proprietary plug-ins, or at least minimize their use. By creating media tags, they sought to ensure that HTML5-compliant browsers would support them natively, without the need for third-party plug-ins.

This is not without its difficulties. Many common audio and video formats are patented, so browser vendors could face similar problems that commercial websites faced with the GIF format. There are also open-source formats (e.g. Ogg Vorbis and Theora), and it has been a constant bone of contention whether HTML5 should standardize support for only those formats. At the moment, it is up to the browser vendors themselves to decide which formats they support. Safari uses QuickTime to play audio and video in the browser. Mobile browsers usually use the phone’s operating system, so the device determines which formats are supported. For this reason, it is usually prudent to offer the same audio or video file in more than one format; I’ll go over this below.

Different media formats have different codecs. A codec (a portmanteau of “coder/decoder”) is an implementation of an encoding algorithm. A format is a standard or specification; a codec is an implementation of the specification. A format (especially a video format) may also be a specification for a container of content: header information, the number of audio tracks that are supported, etc. A format is specified by a MIME type, but a codec isn’t. When possible, it is a good idea to specify both the MIME type (format) and the codec. This is done using the type attribute, assuming the tag has one. I’ll go into details when I talk about each media tag.

The other issue is that the location of the media file is available to any user who looks at the page source. This makes it fairly trivial to download those files. If you’re designing a page for a commercial streaming media site, this is almost certainly something you want to prevent. To encourage sites like this to use HTML5, and not stick with proprietary plug-ins, the W3C created a JavaScript framework called EME (Encrypted Media Extensions) to enable content protection. To put it mildly, this was a controversial decision, because it makes the Internet less open.

Many of these media tags are designed to be manipulated and customized using JavaScript. In fact, if you don’t already know JavaScript, then the media tags could be a good motivation to learn it. However, I don’t assume any knowledge of JavaScript for this article, so I won’t cover this. The media tags will work regardless; the browser can provide basic controls where appropriate.

A piece of audio, like a song or a sound effect. The contents of this tag can include one or more <source> elements, which are used to provide alternate formats. Any other nested text is ignored by browsers that support the <audio> tag, and rendered by those that don’t. It is common to include an <object> element that embeds a plugin-dependent resource (e.g. Flash) as a fallback for older browsers. A plugin-free alternative is to provide download links, using the <a> tag. Note, however, that browsers that do support the <audio> tag will never display this content, even if it does not support any of the supplied file formats.

Common formats:
These are the commonly-supported formats used for web audio. Each one has a specific MIME type. Specifying the MIME type is a good idea, because it lets the browser know if it can display the media, without having to download any of the file itself. You can also specify the codec used, by putting codecs="X" in the type string, where X is a comma-separated list of the codecs used. However, it is optional, and the browser can often tell if they support the media just by examining the MIME type. I’ve included the most common codec strings for convenience.

MP3 (MIME type: 'audio/mpeg; codecs="mp3"')
Unless you’ve been living under a rock, you are probably familiar with MP3. It is a lossy format, and you can encode audio with different compression levels and sample rates to reduce the file size significantly. The MP3 format is supported by every browser except Opera, and by all mobile OS’s. It is not an open format, and certain developers or manufacturers need to acquire a license.
Ogg Vorbis (MIME type: 'audio/ogg; codecs="vorbis"')
This format was developed by Xiph.org as an open-source alternative to the MP3 format. Ogg Vorbis is supported by every modern browser except Internet Explorer, but not by any mobile OS except Android. However, it is the audio codec used by the WebM video format, so it will probably gain support as that format gains popularity.
AAC (MIME type: 'audio/mp4; codec="mp4a.40.5"')
AAC (Advanced Audio Coding) was developed as a successor to the MP3 format. It is the format commonly used for the audio track in a video file, but audio-only AAC files (.m4a) are not unheard of. It is not an entirely open format; using it does not require licensing fees, but developing an encoder does. This format is only supported by modern versions of Internet Explorer and Safari, but most mobile devices can play this formt as well.
WAVE (discouraged) (MIME type: 'audio/wav; codec="1"')
This is a WAVE (.wav) file, commonly encoded with PCM (Pulse Code Modulation). It is not supported by Internet Explorer, which is surprising, since Microsoft and IBM created the format. It is a lossless format, which means that file sizes are an order of magnitude larger than other formats. This is why it is discouraged for use on the web.

My advice: use Ogg Vorbis as the primary audio track (since it’s an open standard), and MP3 as a fallback for non-supporting browsers.

Most of these are common to both the <audio> and <video> tags.

autoplay (discouraged)
The autoplay attribute specifies that the audio file will immediately download and start playing, without any interaction from the user. It is a Boolean attribute, so its value should be autoplay, and if present the audio will start playing automatically. If this attribute is present, then the preload attribute is ignored (see below).

You should really think hard before using this attribute. Most users find autoplay to be extraordinarily annoying. Personally, if I go to a website and a sound starts playing automatically, I immediately close the browser tab and never go back. Some mobile device OS’s (including Apple’s iOS) will not allow automatic playback, since large media files can eat up bandwidth, resulting in higher charges from the mobile carrier.

This attribute specifies that audio controls should be displayed in the browser. It is a Boolean attribute; playback controls are either present or not, and there is no way to specify which controls are present without using JavaScript. The controls usually consist of a play button, a pause button, a volume slider, and a seek bar.
The loop attribute specifies that the audio track should loop continuously. When the end of the audio track is reached, it is immediately “rewound” to the beginning and plays again. This is also a Boolean attribute; a track can be looping, or not, and there is no way to specify how many times it should loop.
muted (uncommon)
Specifies that the audio should be muted. When muted, an audio track’s playback position will still move forward, it simply makes no sound.

This attribute is rarely used with audio, because there are not many situations where it is necessary. It is more commonly used with the <video> element.

This gives a hint to the browser about what part of the audio file should be downloaded when the page is first displayed (and before playback starts). If the autoplay attribute is present, then this attribute is ignored. This is just a hint, and browsers are under no obligation to follow it. Some mobile devices (particluarly iOS) will never preload anything in order to save bandwitdth.

It is an enumerated attribute which can accept these values:

Automatically preload the entire audio file. This is usually unnecessary; most formats support streaming, so playback can start before the entire file is loaded.
Only preload the metadata (for example, the headers of an MP3 or Ogg file). The metadata usually includes the artist, song name, album name, etc. in a music file.
Do not preload anything.
The source of the audio file. This can be either a fully-qualified URL or a relative path. If you want to provide the same audio in multiple formats (which I recommend), then you should use the <source> tag instead. However, this is the attribute that should be targeted if you are changing audio tracks using JavaScript.
A video file. Video files have both audio and moving picture content, and these are encoded using separate codecs.

Common formats:
These are the commonly-supported formats used for web video, their MIME types, and most common codecs.

WebM (MIME type: 'video/webm; codecs="vorbis, vp8"')
This is fairly new video format, but it is becoming more and more popular. The video codec used is usually VP8, which Google released under an open license when they acquired it in 2010. A newer version (VP9) has also been developed, but it is not yet widely supported. The audio codec used is Ogg Vorbis, and it is all wrapped up in a (re-branded) Matroska container, both of which are also open source. WebM is the standard format used by YouTube, and Adobe added support for it in Flash. It is supported by all desktop browsers, but Safari and Internet Explorer require users to install the codecs. It is not supported by any mobile OS except Android.
MP4 (MIME type: 'video/mp4; codecs="avc1.42E01E, mp4a.40.2"')
MP4 stands for MPEG-4 Part 14, a container format. It was directly based on Apple’s QuickTime, and is also the format used in Blu-ray discs. Unsurprisingly, it is not an open format; patent licensing is handled by MPEG-LA (not associated with the Motion Picture Experts Group). The video codec is almost always H.264. The audio codec is usually AAC; others can be used, but they are not widely supported. MP4’s with H.264 and AAC are supported by all browsers except Opera, and by all mobile OS’s.

The H.264 codec that is specified should include the settings used to produce the video, and there are many of them. For example, avc1.42E01E represents H.264 Baseline, AVC level 1. If you don’t know what settings were used, it’s best to omit the codecs, and just use video/mp4 as the type.

Ogg Theora (MIME type: 'video/ogg; codecs="theora,vorbis"')
This is an Ogg file, where the audio is compressed using the Vorbis format, and the video is compressed using the Theora codec. Both codecs are open source. It is being eclipsed by the WebM format, which is also open, but has better video quality. Ogg is not supported by Internet Explorer.

Normally, my advice would be this: provide WebM/VP8 files for most users, and an MP4 fallback (license permitting) for the few users that do not have the codecs installed. However, iOS 3.2 (which powered early iPads and iPhones) has a bug, and only recognizes the first source listed. So, it might be safer to provide MP4 as a default, and use WebM as a fallback.

Most of these are common to both the <audio> and <video> tags. I’ve already gone over these attributes, so my description here will be brief.

autoplay (discouraged)
The video file should immediately download and start playing, without any interaction from the user. It is a Boolean attribute. If you absolutely must autoplay videos, then I highly recommend that you also mute the audio.
Video playback controls should be displayed in the browser. It is a Boolean attribute. The video playback controls include the same ones used for audio playback (play, pause, volume, seek), and usually include a button to go into fullscreen mode.
The height of the video, in pixels. It is a good idea to specify both the width and the height. If you don’t, the browser will try to determine the size from the video (if it’s allowed to preload any of it), or the poster (if one is available). If it can’t determine the height, the default is 300 pixels.

If the height and width are specified, but the aspect ratio doesn’t match the video’s aspect ratio, then the video will be letterboxed. It is probably not a good idea to use anything for the height and width attributes except for the actual height and width of the video; resizing a video in the browser usually looks terrible.

The video track should loop continuously. It is a Boolean attribute.
The audio should be muted; only the video should play. For example: you tell the browser to start playing the video when the page loads, using the autoplay attribute. But you also use muted so the video will play silently, and it won’t be as annoying to the user. This is particularly common if the video is part of an advertisement.
This is an image that will be displayed in the video window, before the video starts playing. The image should be a preview of the video’s content (a still from the video, or perhaps a movie poster). The attribute value should be a URL to an image file; it can be either a fully-qualified URL or a relative path.
This gives a hint to the browser about what part of the file should be loaded before playback. It accepts the same values that the <audio> tag accepts: auto, metadata, and none.
The source of the video file. This can be either a fully-qualified URL or a relative path. As with the <audio> tag, it is better to use multiple <source> tags to supply multiple formats.
The width of the video, in pixels. It is a good idea to specify the size, for reasons I discussed in the section on the height attribute.
This tag defines a source for an audio or video file. It must be a child of either the <audio> or <video> elements. In theory, the user agent should go down the list of sources, and use the first one it encounters that it can recognize. But remember that iOS 3.2 is buggy; see the <video> tag discussion for details.


media (uncommon)
This attribute specifies what type of media the file is optimized for. As an example, you could encode video at a standard resolution for desktop browsers and tablets, and use a smaller resolution for mobile phones. This attribute can use the same values as the media attribute of the <link> tag: a device type (e.g. screen or handheld), screen size (e.g. resolution, device-width, device-height), and more.

This attribute is not yet supported in any browser, which is why it is uncommon. But it is a good idea, and will probably be supported in future browsers, so I don’t want to discourage its use altogether.

The location of the media resource. This can be a fully-qualified URL, or a relative path.

In addition, you can use a fragment-like syntax to specify the playback range. After the file name, append a string in this format: #t=[starttime][,endtime]. (Substitute the start and end times for the bits in square brackets.) You don’t need to specify both times; the defaults are the beginning and end of the file (respectively). The time can be expressed in seconds, or in HH:MM:SS format.

This is the MIME type of the media file, optionally including the codecs used. I gave the most common type values in the discussions about the <audio> and <video> tags.
<track />
This tag can be used to provide literal subtext for a video track (or, less commonly, an audio track). This would include things like subtitles in a different language, or closed captioning for hearing-impaired users. It must be a child of an <audio> or <video> element. It is an empty tag, so it should be properly terminated.

The captions or subtitles should be put in a separate file. The file format recommended by the W3C is called WebVTT (Web Video Text Tracks), which is still in draft. It is a plaintext file, with subtitles preceded by timecodes, and it has a very simple (and HTML-like) markup syntax. If you want the details, you can read the WebVTT Draft Specification at the W3C site. WebVTT is only supported by very modern (post-2012) browsers, and it is only supported on Android mobile devices at the moment.


This specifies that the track is to be enabled by default. This can be overridden in the user agent’s preferences. It is a Boolean attribute.
This attribute tells the browser what type of track this is. It is an enumerated attribute. Valid values are captions, chapters, descriptions, metadata, or subtitles. If the type is subtitles, then the srclang attribute is required (see below).
Specifies a human-readable name for this track. For example, if you are providing Spanish subtitles, the label might be “Spanish.”
The source file for the track. This can be an absolute URL or a relative path. This attribute is required.
The language that the track’s source is written in. This should be a language code, possibly followed by a country code, e.g. en-US. If the kind attribute has the value subtitles, then this attribute is required.
A blank canvas. By default, it has no borders, and no content. Its purpose is to be used by JavaScript to draw graphics. There are JavaScript methods to draw basic shapes, text, images, and so forth, and the canvas can recognize any JavaScript events. So, the <canvas> element could be used for almost anything: dynamically-generated charts, animations, even full-fledged browser games. For Flash designers, it is relatively easy to modify existing code to use the <canvas> element instead. But since I don’t presume any knowledge of JavaScript, the details are outside the scope of this article.

This element may have content in between the opening and closing tags. This will be ignored by user agents that recognize the <canvas> tag, but rendered by those that don’t. This means you can include fallback text as the content, for people that are still using older browsers. If you also have a Flash version, you can display it as a fallback by using an <object> tag.


The height of the canvas, in pixels.
The width of the canvas, in pixels.

Deprecated Media Tags

A Java applet. Java applets were a big deal in the 90’s, but are largely obsolete nowadays. If you are still using Java applets for some bizarre reason, use the <object> tag instead.
Embed a media resource. This is an empty element, so it is impossible to provide fallback text for user agents that can’t display the resource.

Though widely used, this tag was never part of any HTML standard, and it was officially deprecated when the <object> tag arrived in HTML 4.01. The HTML5 standard revived it as an integration point for external content. I would still use the <object> tag instead.


About Karl

I live in the Boston area, and am currently studying for a BS in Computer Science at UMass Boston. I graduated with honors with an AS in Computer Science (Transfer Option) from BHCC, acquiring a certificate in OOP along the way. I also perform experimental electronic music as Karlheinz.
This entry was posted in HTML and tagged , . Bookmark the permalink.

4 Responses to A Guide to HTML

  1. Ben says:

    You probably know this, but the self-closing-ness of your tags are likely to be totally ignored by the browser unless you set the mime type to xhtml! For example, in most browsers this
    This is a paragraph
    will render exactly the same as this:
    This is a paragraph

    A common gotcha is thinking that you can use a self-closing script tag, e.g.

    instead of

    More on this on stackoverflow:

    So there can be arguments for doing this for style or tool support, but the browser really doesn’t care.

    • Ben says:

      wow, looks like wordpress doesn’t escape tags. Sorry, but hopefully the stackoverflow article explains well enough

      • Karl says:

        Also, about the tags – nope, WordPress does not excape HTML; you can use it to mark up comments (as I did just now), so it really can’t do that. For HTML tags, you have to use the &lt; and &gt; escape sequences. I also had to do this when I wrote the article, so I know how much of a PITA it is.

    • Karl says:

      Ben: First of all, thanks for taking the time to read the article. I need all the help I can get…

      The “self-closingness” issue applies only to tags that do not represent empty elements, and that includes the <script> tag. It’s supposed to contain text data (the actual JavaScript code). Trying to make these tags self-closing is not valid XHTML, and browsers will consider it “tag soup.”

      If the tag is actually self-closing – like the <br /> or <input /> tags – then the XHTML standard demands that they be properly terminated, or they won’t validate. The HTML standard (even HTML5) does not, but since XHTML is the one that has been used for years, I think it’s better to include the terminating slash.

      However, the Stack Overflow post did show something else that I wasn’t aware of: the <p> tag cannot contain other block-level tags, like <div>. (Inline tags are fine.) If you try to do this, the browser will consider it “tag soup” and automatically treat it as a tag with empty content. In other words, <p><div>Hello, world!</div></p> will turn into <p></p><div>Hello, world!</div><p></p>.

      I’ll update the article with this info. So, thank you for pointing this out. Please let me know if you find anything else in the article that needs work.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s