Re: Timed tracks

On Fri, 07 May 2010 05:53:20 +0800, Tab Atkins Jr. <>  

> On Thu, May 6, 2010 at 2:25 PM, John Foliot <> wrote:
>> Tab Atkins Jr. wrote:
>>> SRT is the closest-to-ideal existing format,
>> Tab, with all due respect, what documented facts is this bold assertion
>> based upon? <em>URLs would be most appreciated here, as the Media  
>> Sub-Group
>> are assembling a needs requirement document at this time.</em>
> All of the use-cases of actual caption use on the web, collected on
> the WHATWG wiki at
>  Additionally, API-level access use-cases for captions on the web have
> been collected at
>> As co-chair of the Media Sub-Group at the W3C Accessibility Task Force  
>> for
>> HTML5, active participants (including, significantly, engineers from the
>> related browser manufacturers) have been discussing Time Text formats  
>> for
>> some time now, and a recent survey (2010-03-08 to 2010-03-11) of the  
>> larger
>> a11y Task Force showed almost equal support for the minimal SRT format  
>> as
>> well as a more robust format, likely DFXP/TTML and/or a profile of that.
>> -
>> The general consensus (and others are free to correct me) was that SRT  
>> was
>> at best a minimal time-stamp format that could be used, but that it did  
>> not
>> meet the 'robustness' test for all aspect of accessibility. Suggesting  
>> that
>> it is the "closest-to-ideal" is pure folly and opinion at this time, and
>> does not accurately reflect the opinion of those who are working  
>> closely at
>> this subject (again, including engineers from Microsoft, Apple, Opera  
>> and
>> Mozilla directly involved with <video> implementation in the browsers).  
>> In
>> fact, Maciej himself suggested (in his survey response): "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."
> Indeed, plain SRT is pretty minimal, and doesn't address many of the
> documented use-cases.  But it's very simple to both author and parse,
> and the extensions needed to make it handle all the aforementioned
> use-cases are pretty minimal.  It's also pretty common, apparently
> especially so amongst amateur subbers, which implies that it probably
> addresses the needs and desires of average authors pretty well.
> It may be that we end up needing to support multiple formats, such as
> perhaps a profile of TTML.  But I'd like to avoid that if at all
> possible, and from what I understand implementors would too.

I am one of those browser vendor representatives that voted in the linked  
survey, supporting SRT only. From what I have read of the TTML spec, I do  
not want to support it in Opera, mainly because it fails to make use of  
CSS for styling.

>> Continue to expect significant and vocal opposition to this newly
>> re-invented Time-stamp wheel, which apparently sprang to life earlier  
>> this
>> week from the editor of the WHAT WG, as a complete and total surprise to
>> Media Captioning experts and Accessibility specialists of all stripes  
>> within
>> the W3C (such as Geoff, who's years of involvement within NCAM/WGBH -  
>> the
>> 'inventors' of captioning for television "video media" - carries  
>> significant
>> weight, research and experience when it comes to understanding both user
>> requirements, as well as an understanding of implementation issues).
> No, the use-cases have been collected for a while, in hand with
> significant effort from Silvia Pfeiffer.  No need to invent a fiction
> of Hixie creating these things out of whole cloth.

Like Silvia, I have also been taking part in this discussion. I don't  
think WebSRT is going to be immediately perfect, but the general direction  
is one I approve of. If there are use cases it cannot serve, now is the  
time to raise them. It may very well turn out that we need a second  
complex format, but that doesn't negate the usefulness of WebSRT.

(Hixie has participated very little in these discussions, so it's hard to  
frame this as his creation alone.)

Philip Jägenstedt
Core Developer
Opera Software

Received on Friday, 7 May 2010 04:35:43 UTC