w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire Consensus check on formats for media text associations
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: cooper@w3.org, mike@w3.org, janina@rednote.net,
This questionnaire was open from 2010-03-08 to 2010-03-11.
20 answers have been received.
Jump to results for question:
1. Formats for media text associations
summary | by responder | by choice
The media subgroup of the HTML Accessibility Task Force, as part of their work to help improve accessibility support for the HTML5 media elements, would like to request feedback from all members of the Task Force about which format(s) to support for external associated text resources—particularly caption and subtitle file formats.
As part of the Media TextAssociations proposal, one or more file formats for external associated text will need to be recommended as baseline format. Thus far, SRT (the SubRip format), DFXP (also called W3C Timed Text), and smilText (SMIL's version of timed text) have been proposed as baseline formats. However, other formats exist that may also be relevant.
The subgroup is interested to gain a full understanding of the requirements and preferences that people have.
Which format or combination of formats do you think should be introduced as the baseline for external associated text?
Summary
| Choice | All responders |
|---|---|
| Results | |
| DFXP | 14 |
| smilText | 7 |
| SRT | 15 |
| Other formats (provide the details in the Comment field) | 5 |
Skip to view by choice.
View by responder
Details
| Responder | Formats for media text associations | Comments |
|---|---|---|
| Silvia Pfeiffer |
|
I would suggest starting with SRT without any special markup, and introducing/adapting a simple basic profile for DFXP. For use at a later stage, a richer DFXP profile would need to be developed in collaboration with the Timed Text working group. Further, there needs to be a clear mapping of both srt and DFXP into HTML5/CSS/JavaScript for presentation. |
| David Bolter |
|
SRT makes sense to me, if we want to start simple. |
| Eric Carlson |
|
I suggest we start with a simple format and add a richer format once we have some implementation experience. |
| John Foliot |
|
.sbv - Native time-stamp format currently used at YouTube (which is likely the largest repository of captioned videos on the planet, and given their recent announcement of last week, likely to be growing by leaps and bounds) .scc - Binary format used for Line 21 captioning (being produced TODAY by large commercial content providers, as well as the *ONLY* caption format currently supported on iPhone. While technically not an out-of-band format, I believe that it needs to be acknowledged w.r.t. the Media MultitrackAPI which currently is absent any comment on supported caption formats) W.R.T. DFXP: there has been some discussion but no resolution on *how much* DFXP support should be provided, and questions whether a number of different profiles of DFXP, with increasing amounts of "richness" be developed - there are already 3 public profiles available - which one (if any) does this survey refer to? As Matt May (and others) have pointed out (http://lists.w3.org/Archives/Public/public-html-a11y/2010Mar/0102.html), mapping the basic start and end times of any time-stamped document to a basic DFXP profile is not only quite easy, but such a profile currently exists: http://www.w3.org/TR/ttaf1-dfxp/#profile-dfxp-presentation W.R.T. "Requiring any format that browser vendors aren't expressing interest in supporting will mean nothing in practice..." a)I think it is counter-productive to have engineers telling the accessibility community what should and shouldn't be supported. b) If that were the sole criteria for implementing and documenting new aspects of HTML5, it is very likely that the entire Web Forms 2.0, which currently is NOT SUPPORTED in FireFox, Chrome, IE and only partially supported in WebKit should be dropped from the spec at this time, as it appears that only Opera has chosen to support it at this time. |
| Maciej Stachowiak |
|
I don't think it's necessary to require a specific format for the initial proposal. It seems like requiring any one format will just make it more controversial. However, if there is a baseline, SRT seems to be the one that has the most support among implementors, and will likely be supported in all major implementations of <video>, so it would probably be ok to make it a baseline. |
| Jim Allan |
|
|
| Ian Hickson |
|
Whatever we add should be really simple, shouldn't be presentational, and should be compatible with a large set of existing content. |
| Leif Halvard Silli |
|
A decent mark-up solution for media text associations seems crucial for the usability of <video> and <audio> (else one will turn to Flash and other plug-in formats for that purpose). I put my vote on DFXP, allthough I have nothing against smilText either. The SAMI format should be considered, because it is literally a profile of HTML+CSS (with a handful of special elements). |
| Geoff Freed |
|
-- DFXP/TTML must be a part of this proposal now, in some form, and should not be relegated to some later version. Rather than implementing the full DFXP/TTML spec, our goal should be to specify a basic baseline profile. -- The simple popularity of SRT is not a reason for it to supersede other formats in our recommendation. Its widespread use warrants consideration for its inclusion but not at the expense of other formats (including SmilText) that support advanced text-display features which are not part of SRT. |
| Martin Kliehm |
|
DAISY |
| Denis Boudreau |
|
|
| Philip Jägenstedt |
|
Requiring any format that browser vendors aren't expressing interest in supporting will mean nothing in practice, which was shown clearly by the codec debacle for <video>. Most representatives for browser vendors appear to agree that some complex format is eventually needed, but unwilling to commit to one right now. |
| David Singer |
|
There seems to be some discrepancy between the question ('what should be recommended') and the answers to date ('what should be required'). I think recommending SRT support makes sense. I think we'll need to experiment with DFXP and what 'profile' of it is appropriate. |
| Steve Faulkner |
|
|
| Markku Hakkinen |
|
SRT, given its wide use. DFXP because a standard, XML-based format should be recommended path for caption/subt markup. smilText, because if you've done DFXP support, smilText should not be an added burden. |
| Laura Carlson |
|
|
| Dick Bulterman |
|
|
| Gregory Rosmaita |
|
1. i agree with Geoff and JohnF: DFXP/TTML MUST be a part of this proposal now and should NOT be relegated to some later version; i also support the goal of implementing a basic baseline profile; 2. i also strongly agree that the popularity of SRT is NOT a reason for it to supersede other formats in HTML5; its widespread use warrants consideration for its inclusion but NOT at the expense of other formats -- especially SmilText -- which support advanced text-display features which are NOT part of SRT. |
| Matthew May |
|
I support SRT as _one of_ the formats, because it should be simple enough to do. However, I _do not_ support SRT as the only format. It's a step backward from where online captioning is today. I think that further surveys on this question should more clearly define what the minimum set should be. DFXP must be in the minimum set. SRT doesn't have to be, IMO, but solely for convenience sake and implementability, I'm in favor of putting it in there. If there's a vote where SRT-only is an option, I will vote no. |
| Bruce Lawson |
|
Note first that this is a personal opinion; I don't represent Opera (my employer). It seems to me that dfxp at its most basic offers much the same as .srt, but unlike srt is extensible and can be built upon more easily (different languages, incorporating markup and allowing styling). As we're starting afresh, I think we should choose a foundation that can be built upon. |
View by choice
| Choice | Responders |
|---|---|
| DFXP |
|
| smilText |
|
| SRT |
|
| Other formats (provide the details in the Comment field) |
|
More details on responses
- Silvia Pfeiffer: last responded on 8, March 2010 at 10:41 (UTC)
- David Bolter: last responded on 8, March 2010 at 14:45 (UTC)
- Eric Carlson: last responded on 8, March 2010 at 15:43 (UTC)
- John Foliot: last responded on 8, March 2010 at 18:01 (UTC)
- Maciej Stachowiak: last responded on 8, March 2010 at 19:28 (UTC)
- Jim Allan: last responded on 8, March 2010 at 23:10 (UTC)
- Ian Hickson: last responded on 9, March 2010 at 01:28 (UTC)
- Leif Halvard Silli: last responded on 9, March 2010 at 01:52 (UTC)
- Geoff Freed: last responded on 9, March 2010 at 02:02 (UTC)
- Martin Kliehm: last responded on 9, March 2010 at 20:02 (UTC)
- Denis Boudreau: last responded on 10, March 2010 at 03:32 (UTC)
- Philip Jägenstedt: last responded on 10, March 2010 at 06:39 (UTC)
- David Singer: last responded on 10, March 2010 at 07:48 (UTC)
- Steve Faulkner: last responded on 10, March 2010 at 09:13 (UTC)
- Markku Hakkinen: last responded on 10, March 2010 at 23:48 (UTC)
- Laura Carlson: last responded on 11, March 2010 at 12:33 (UTC)
- Dick Bulterman: last responded on 11, March 2010 at 14:35 (UTC)
- Gregory Rosmaita: last responded on 11, March 2010 at 15:42 (UTC)
- Matthew May: last responded on 11, March 2010 at 17:31 (UTC)
- Bruce Lawson: last responded on 12, March 2010 at 02:22 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project