[whatwg] Introduction of media accessibility features

[Silvia Pfeiffer]

On Thu, Apr 15, 2010 at 12:24 PM, 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.

As already stated: we will need a defined mapping that browsers adhere
do. This mapping, however, does not need to embrace all TTML features.
We just commit to implementing only those features in the mapping and
then authors are very clear on what is supported and what is not.

Even if we define a new format (which I am increasingly warming up
to), I think we will still need to do this mapping. Otherwise, some
browsers will implement support for TTML (I'm thinking in particular
IE, since MS already supports DFXP in Silverlight, see
http://www.w3.org/2009/05/dfxp-results.html) and others won't and then
we end up in the mess that you are describing. I think TTML is that
important in professional captioning applications that we can't
ultimately avoid it.


>> 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.

I think throwing timed elements directly into HTML is a bad idea. A
HTML page has no notion of time and neither should have. What timeline
do you synchronise a timed element with? What if there are several
media elements on the page? What if there are no media elements on the
page? Do we introduce a timeline for the Web page?

I prefer sticking with the external approach. RSS feeds are also never
made part of a Web page - only a parsed version thereof. The same
should be the case with time-aligned text formats.

Cheers,
Silvia.