[whatwg] Introduction of media accessibility features
Philip Jägenstedt
philipj at opera.com
Wed Apr 14 19:57:27 PDT 2010
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
More information about the whatwg
mailing list