RE: Timed tracks

Well SRT has no display model, so while CSS not required; it's not terribly useful till you either make one up or specify what CSS works with it. The former isn’t very helpful from  an interoperability point of view, the latter is essentially what TTML is, barring a bit of XML syntax, and a time model which I'm sure you can handle.

>> A WebSRT-supporting UA just has to be able to handle italic, bold, ruby, newlines, and bidi text, plus a little bit of positioning.

Well I would argue it’s a bit more than that, and can point you at seven years or so of debate on the subject from caption industry professionals to back it up, but even if it were just that, that all requires specification, which HTML isn’t going to help you with; so you'll be looking at the CSS model, therefore you'll be needing to turn SRT into a format amenable to CSS. Once you've done that you’ve replicated about half of TTML. Then all you have to do is formalise the timing model and metadata.

>>Note as well that we don't want SRT.  It is indeed too minimalist to handle enough of the use-cases that were found.  But it provides a base from which to develop WebSRT, and doesn't require complexity that we don't need.

Great, so we are agreed SRT is a non starter. What complexity is it in TTML you don’t need then, and I'll see if I can use the TTML profile mechanism to take it out.

-----Original Message-----
From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
Sent: Friday, May 07, 2010 7:15 PM
To: Sean Hayes
Cc: Philip Jägenstedt; public-html@w3.org
Subject: Re: Timed tracks

On Fri, May 7, 2010 at 11:02 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
> I would point out however that a lot of the resistance TTML has had in the past is due to the perception that it is already too complex, so adding all this CSS3 stuff, while fun and in some cases justifiable; will only serve to make it more so.  I'm also somewhat confused as to why on the one hand you want SRT, which is utterly minimalist and on the other you want this extreme complexity.

Note the *extremely* important difference between *allowing* this sort of complexity via CSS for UAs that support CSS, and *requiring* it as a fundamental part of the format that text tracks are specified in.

WebSRT does not require CSS, though it does define how CSS can interact with it.  A UA that doesn't support any CSS can still display a WebSRT file in a completely acceptable manner.  A WebSRT-supporting UA just has to be able to handle italic, bold, ruby, newlines, and bidi text, plus a little bit of positioning.

Note as well that we don't want SRT.  It is indeed too minimalist to handle enough of the use-cases that were found.  But it provides a base from which to develop WebSRT, and doesn't require complexity that we don't need.

~TJ

Received on Friday, 7 May 2010 18:53:46 UTC