[whatwg] Introduction of media accessibility features

Anne van Kesteren annevk at opera.com
Thu Apr 15 22:32:11 PDT 2010

On Thu, 15 Apr 2010 09:59:06 +0900, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:
> On Thu, Apr 15, 2010 at 3:19 AM, Tab Atkins Jr. <jackalmage at gmail.com>  
> wrote:
>> +1 to Henry's suggestion of just using two formats: SRT, and SRT +
>> (possibly some subset of) HTML+CSS, where the latter is simply a
>> normal SRT file with HTML allowed where it would normally only allow
>> plaintext for the caption.
>> That seems to be the minimal change that can address this case, and
>> appears to be a fairly logical extension of an existing widespread
>> format.
> A spec would need to be written for this new extended SRT format.

A spec would also need to be written if we go for this new  
TTML-minus-certain-features-and-using-CSS-rather-than-XSL-FO format. That  
would probably be worse since we would be forking an existing format in an  
incompatible way.

> Also, if we are introducing HTML markup inside SRT time cues, then it
> would make sense to turn the complete SRT file into markup, not just
> the part inside the time cue. Further, SRT has no way to specify which
> language it is written in and further such general mechanisms that
> already exist for HTML.

What general mechanisms are needed exactly? Why is language needed? Isn't  
that already specified by the embedder?

> I don't think SRT is the right base format to start extending from.
> That extension doesn't give us anything anyway, since no existing SRT
> application would be able to do much with it. It is not hard to
> replicate the SRT functionality in something new. If we really want to
> do "SRT + HTML + CSS", then we should start completely from a blank
> page.

It makes things easier for people familiar with authoring SRT. It also  
makes it easier to change existing SRT files into rich SRT files.

Anne van Kesteren

More information about the whatwg mailing list