The Media TextAssociations proposal
introduces declarative markup for media elements to
reference external associated and time-synchronous text resources. The
aim is to reference in a standard way external captions,
subtitles, and, possibly, textual audio descriptions—as well as, potentially,
other time-aligned text, such as lyrics, karaoke, or ticker text. The
proposal is written such that it can later easily be extended to
include external associated audio and video resources, too.

The media subgroup believes that this proposal is sufficiently developed to
propose it to the HTML WG as a first step towards addressing the following:

This proposal is harmonised with the Media Multitrack API proposal to expose a
uniform interface to media tracks independent of whether they come
from inside the main media resource or from an external resource.

The proposal is written as a change request and, if applied to the
HTML5 specification, will encourage trial implementations in Web
browsers.

Do you support presenting the proposal as a change request to the HTML working
group?

Submit this proposal, with the following changes, to the HTML WG as a decision of the task force.

4

Do not submit this proposal to the HTML WG for the following reasons.

Details

Responder

Media Text Associations proposal

Comments

Silvia Pfeiffer

Submit this proposal to the HTML WG as a decision of the task force.

The HTML WG is urgently waiting on a proposal to address these issues and this proposal is in good state after long discussion and progression to concensus within the media subgroup. It is ready for presentation to the larger HTML WG.

Philip Jägenstedt

Submit this proposal, with the following changes, to the HTML WG as a decision of the task force.

I agree with most of the proposal (since I was involved in the discussions leading up to it). It is still missing the CSS half of things, but that isn't something for the HTML WG to consider anyway. I don't agree with mandating DFXP at this point unless there is some browser vendor who is really enthusiastic about it and actually wants to implement it.

Geoff Freed

Submit this proposal, with the following changes, to the HTML WG as a decision of the task force.

I agree with most of the proposal and would like to see it move forward. I disagree with the use of SRT as a baseline text format for reasons already stated in list discussions. I would prefer that we use a subset or profile of DFXP/TTML, or consider the use of SmilText, for the display of timed text.

Eric Carlson

Submit this proposal, with the following changes, to the HTML WG as a decision of the task force.

I generally agree with this proposal (I was also involved in the discussions leading up to it), with the following changes:

+ We should not mandate DFXP at this time. It has many features that will complicate implementation significantly which are not needed for this proposal. We should help define a DFXP profile that is more suitable for our needs.

+ The 'enabled' attribute on a <track> in a <trackgroup> should be invalid, as the UA is responsible for selecting the most appropriate track from the alternates.

Dick Bulterman

Submit this proposal, with the following changes, to the HTML WG as a decision of the task force.

W3C currently has two existing timed text formats: smilText (part of the SMIL 3.0 rec [2008]) and DFXP (currently in CR). My concern with the current proposal is that a new internal markup syntax is being defined that is not compatible with either smilText or DFXP. Integrating DFXP as an internal format may be difficult; for smilText, this would be trivially easy. I would suggest considering smilText as a light-weight authoring format for incidental timed text, caption, foreign language subtitles and for motion text. DFXP should be supported as a full-featured language for professional captions. I am against support for SRT as a W3C format: it is not XML, has no styling or motion capability and is totally non-extensible. A simple conversion from SRT to smilText or DFXP could ensure that legacy content is not lost. Note that both smilText and DFXP can do everything that SRT can do. Both have simple layered models that allow incremental deployment. In my opinion (from a SYMM WG perspective), smilText has a slight advantage for an initial format because: the syntax is trivial to author; it cna be used internally and externally; it is a streamable formal (DFXP is not); and it support motion text (DFXP does not). For details on the external smilText profile, see:
http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-text-profile.html.

The module definitions for smilText are available at:
http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-text.html

(Note that, like all of SMIL, smilText is modularized: you only need to select the modules that you need for a given level of implementation.)