[whatwg] Introduction of media accessibility features

On Thu, 15 Apr 2010 10:24:27 +0800, Tab Atkins Jr. <jackalmage at gmail.com>  
wrote:

> On Wed, Apr 14, 2010 at 5:59 PM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> If TTML creates specs that cannot be mapped, then those are ignored.
>> All we are basically committing to would be that a best effort is done
>> on the mapping. Just like with SRT we would do a best effort on the
>> mapping - there are SRT files now that have more than just plain text
>> in them. But we would not commit to interpreting every special markup
>> that some author came up with that worked in his particular player.
>>
>> I think the dependencies between external timed text formats and HTML5
>> are much less than e.g. the dependency on SVG. TTML is not supposed to
>> be a native Web format in my eyes. It is just interpreted for the Web.
>
> "Best effort" mapping won't be enough as soon as this gets really
> picks up.  Authors can be crazy about the placement of things.  We'll
> end up having to define the exact mapping, or else have compat bugs on
> all the browsers.
>
>
>> A spec would need to be written for this new extended SRT format.
>> 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.
>>
>> 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.
>
> I'm sympathetic to this sentiment.  SRT seems to be the simplest
> widespread format that would "just work", so extending it for the
> other cases just feels like a potential win.  But it might not be,
> sure.
>
> Random brainstorm: we already had an element meant to mark up
> dialogues, <dialog>.  Perhaps we can revive it, give it the minimal
> extensions necessary to handle our use-cases, and use that for our
> markup-heavy format?  Additional benefit: the element could then be
> included directly in the page as well, as a transcript.
>
> ~TJ
>

While I don't favor TTML, I also don't think that extending SRT is a great  
way forward, mostly because I don't see how to specify the language (which  
sometimes helps font selection), apply document-wide styling, reference  
external style sheets, use webfonts, etc...

I actually quite like the general idea behind Silvia's  
http://wiki.xiph.org/Timed_Divs_HTML

This is somewhat similar to the <timerange> proposal that David Singer and  
Eric Carlson from Apple have brought up a few times.

No matter the syntax, the idea is basically to allow marking up certain  
parts of HTML as being relevant for certain time ranges. A CSS  
pseudo-selector matches the elements which are currently active, based on  
the current time of the media.

So, the external subtitle file could simply be HTML, with <track> acting  
much like an iframe with the only difference that the current time of the  
document is given by the embedding <audio> or <video>. Something like this:

<!doctype html>
...
<timerange start="1" end="2">Hello</timerange>
<timerange start="10" end="12">The End</timerange>
...

The default stylesheet would be something like this:

:before-timerange, :after-timerange {
   display: none;
}
:in-timerange {
   display: block;
}

The styling issue is trivially solved, anything you can normally do is  
possible here too.

Pros:
  + Styling using CSS and only CSS.
  + Well known format to web authors and tools.
  + High reuse of existing implementations.
  + You could author CSS to make the HTML document read as a transcript  
when opened directly.
  + <timerange> reusable for page-embedded timed markup, which was the  
original idea.

Cons:
  - Politics.
  - New format for subtitle authors and tools.
  - Not usable outside the web platform (i.e. outside of web browsers).
  - <timerange> is a bit verbose, but that can be changed to whatever we  
want.

Thoughts?

-- 
Philip J?genstedt
Core Developer
Opera Software

Received on Wednesday, 14 April 2010 19:57:27 UTC