Wednesday, May 5th, 2010

The new element has been added to the HTML5 spec

Category: HTML, Standards

It is always fun to get a new tweet from Mr. WHATWG and these came through recently:

HTML5: Captions – Stage 1: the <track> element.

HTML5: Captions – Stage 2: the IDL additions.

HTML5: Captions – Stage 3: defining what a timed track and a timed track cue are.

John Dyer noticed the new <track> element too, and noted how useful they would be for his multi-lingual HTML5 video player for a school’s online education program.

Here is what the spec has to say about the new element:

The track element allows authors to specify explicit external timed tracks for media elements. It does not represent anything on its own.

The kind attribute is an enumerated attribute. The following table lists the keywords defined for this attribute. The states given in the first cell of the rows with keywords give the states to which those keywords map.

  • subtitles: Translation of the dialogue, suitable for when the sound is available but not understood (e.g. because the user does not understand the language of the media resource’s soundtrack).
  • captions: Transcription of the dialogue, suitable for when the soundtrack is unavailable (e.g. because it is muted or because the user is deaf).
  • descriptions: Textual descriptions of the video component of the media resource, intended for audio synthesis when the visual component is unavailable (e.g. because the user is interacting with the application without a screen while driving, or because the user is blind).
  • chapters: Chapter titles, intended to be used for navigating the media resource.
  • metadata: Tracks intended for use from script.

Posted by Dion Almaer at 5:58 am

3.3 rating from 3 votes


Comments feed TrackBack URI

Seems to me like HTML 5 VIdeo/Audio are becoming more and more SMIL-like. I’m not complaining by any means, but why not adopt SMIL instead of reinventing the wheel?

Comment by rasmusfl0e — May 5, 2010

“kind”? Really? Why not “type” or “rel” or something a little less awkward? “rel” kinda makes sense, as it defines the relationship between the track and the media element. “Kind” feels… weird.

Comment by ajacksified — May 5, 2010

This article seems to be about the ‘track’ element. Where is the information about the ‘new’ element as promised in the title?

Comment by okonomiyaki3000 — May 5, 2010

To okonomiyaki3000, is kind of a running joke of amateur mistakes like forgetting to escape HTML, or forgetting to not leech bandwidth, or forgetting the dimensions of their content area—which is pretty hilarious, given the content of the site. If you look at the source, you’ll see a track element in the title, unescaped. You probably noticed this and made a funny, but I spelled it out because Dion (et al) never seem to realize how many of these mistakes they make, and it a little jab here and there might serve as a friendly reminder. (Thanks for the news, guys! No harm intended. But really, it’s pretty silly how often these mistakes are made.)

* * *

To ajacksified,

I’m not really sure how I feel about the naming of a “kind” attribute (it’s not immediately offensive, but it does seem awkward), but “type” and “rel” are semantically different from what the proposed “kind” attribute aims to achieve: “type” refers to a mime-type (not covered by “kind”), and “rel” describes a relationship (also not covered by “kind”). I think the meaning of both of those attributes on a track element should be specified (“type” referring to the mime-type of the external resource[s] in “kind” [or whatever its replacement name might be], and “rel” referring to any timed-track media [animated image, audio, video] supported directly by HTML).

Comment by eyelidlessness — May 5, 2010

I think ajacksified has it right, “type” is the appropriate attribute name in this case. Yes, “type” frequently refers to mime-types (for instance, in the script and style tags), however it also is used to differentiate an element’s behavior and/or appearance, as in the input and button elements. Unless a case can be made that the element requires specifying both a mime-type and an enumerated value, there’s no reason to invent a new attribute when its function is the same as one already widely in use.

Comment by skippyK — May 26, 2010

Leave a comment

You must be logged in to post a comment.