FW: HTML 5, SMIL, Video

------ Forwarded Message
From: dcab <Dick.Bulterman@cwi.nl>
Date: Fri, 19 Feb 2010 06:21:28 -0500
To: John Foliot <jfoliot@stanford.edu>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Geoff Freed <geoff_freed@wgbh.org>, <public-html-a11y@w3.org>, <markku.hakkinen@gmail.com>, <symm@w3.org>
Subject: Re: HTML 5, SMIL, Video

Hi John and Silvia,

A couple of comments that address the batch of recent mails:

On the availability of smilText, see:
   http://ambulantplayer.org/Toys.shtml
There are two items here of interest -- the smilText javascript engine,
and a simple captioning interface for youTube video.
(Silvia will be thrilled to see that the captioning tools allows you to
   export to either smilText or .srt!!)
[Note also that the in-line version of smilText requires timing markers
in the form: <tev ...> </tev>. This is a browser XML problem, not a
smilText issue.]

If you take the time to read the introduction to the smilText spec,
things will be come clearer. Those with even more time could consider
reading the timed text chapter from my SMIL-3.0 book:
       http://xmediasmil.net/Chapters/SampleChapter.pdf



On .srt -- my view is that people are making a passive choice for SRT.
It is a format that is easy to hand edit and is playable on the desired
target platform. Other than that, it has no inherent value -- it has no
path to expansion, it has no broader model, and it has no easy fit as an
in-line format for HTML pages. Instead of wasting time on an RFC for
SRT, we should simply provide a converter to whatever format is
ultimately chosen. Anyone who values placing captions in Web pages can
than move their old content in nano-seconds.

As for the future, it seems to me that we need a format that can be used
   in-line in a HTML document (for incidental labels, captions or
(sub)titles), and as an external specification. I don't see ANY
advantage to SRT here. Note that counting the current number of
smilText, DFXP or SRT files out there is in no way a useful measure --
as long as we don't disenfranchise users with existing content, then the
added value of having timed text in web pages will hugely compensate for
the initial conversion. (When HTML was introduced, there were way more
.doc files out there than .html....)

We debated the SRT issue intensely within SYMM before starting on
smilText. Our reason for not using SRT was that there is no growth path
based on any inherent value in the SRT format -- everything you would
potentially want to do for future enhancement would have to be added
anyway. What are these enhancements? We felt:
   - text styling
   - text motion
   - suitability for Labels, informal text annotation (such was: wow,
this is cool!)
   - the potential for using text as a temporal navigation tool by
allowing (timed) anchors in captions.

 From my perspective, DFXP goes a long way to meet the needs of
professional captions and subtitles, but the in-line integration in HTML
is not trivial. SRT provides very basic captions, but it doesn't support
styling, incremental captioning, (the potential for) linking and
navigation, text motion or even conditional text display/removal. The
goals for smilText were to support all of these, with an engine that
could be implemented in an afternoon and a user encoding burden that was
as easy (yet more flexible) as that of SRT.

The bottom line (for me):
a) support SRT via a converter (for reusing legacy content)
b) choose a format that has a model for the mid- and longer-term
c) provide authoring support from day-1 to help new content to be
created easily.

I am convinced that the 'kids' that John spoke of care about impact.
Having your content be supported within a web page is much, much, much
more important that having it be in any particular format.

-d.

(PS: this is not being forwarded to the a11y list yet -- could someone
do this for me? Thx.)


------ End of Forwarded Message