[whatwg] Introduction of media accessibility features

[Anne van Kesteren]

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
http://annevankesteren.nl/