The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
This questionnaire was open from 2010-03-02 to 2010-03-06.
5 answers have been received.
Jump to results for question:
The media subgroup of the HTML Accessibility Task Force, as part of their work to help improve accessibility support for the HTML5 media elements, has developed a first draft proposal for declarative markup to associate external alternate timed text with media resources.
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 to the HTML WG as a decision of the task force.||1|
|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.|
|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 ) 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:|
The module definitions for smilText are available at:
(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.)
The following persons have not answered the questionnaire:
Send an email to all the non-responders.