On Thu, 15 Apr 2010 10:24:27 +0800, Tab Atkins Jr. <jackalm...@gmail.com>
wrote:
On Wed, Apr 14, 2010 at 5:59 PM, Silvia Pfeiffer
<silviapfeiff...@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
