[whatwg] Introduction of media accessibility features

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

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