W3C home > Mailing lists > Public > public-html-a11y@w3.org > February 2010

Re: HTML 5, SMIL, Video

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 19 Feb 2010 10:52:22 +1100
Message-ID: <2c0e02831002181552o331b29eambd5a3bc4468e12b4@mail.gmail.com>
To: Geoff Freed <geoff_freed@wgbh.org>
Cc: Dick Bulterman <Dick.Bulterman@cwi.nl>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, "markku.hakkinen@gmail.com" <markku.hakkinen@gmail.com>, "symm@w3.org" <symm@w3.org>
On Thu, Feb 18, 2010 at 11:41 PM, Geoff Freed <geoff_freed@wgbh.org> wrote:
> one brief comment from me below; i’m out of the office today and will have
> to save my other comments for tomorrow.
> geoff/wgbh
>> On 2/18/10 7:09 AM, "Dick Bulterman" <Dick.Bulterman@cwi.nl> wrote:
>> (SRT, which has huge user uptake, is not sufficiently easier to use than
>> smilText, it is not XML and there is nobody who really 'owns' it. From a
>> standardization perspective, I would tend to view it as a non-starter,
>> were it not that it provides lowest common denominator support -- but,
>> so does Fortran.)
> GF:  I very much agree here with Dick.  The things that make me most
> apprehensive about SRT are...
> -- it has no ownership
> -- it has no standards-group backing
> -- it has very little, if any, styling (plz correct me if I’m wrong)

There are several people in the WG that have already proposed to write
a RFC for srt. It will be really simple to do, mostly because styling
will be left out and left to CSS. That is actually an advantage of srt
over any other choice. In this respect it compares more to an RSS feed
format than to a markup format.

Its huge uptake online is the big advantage here, so it would be more
productive to look at it as identical to the most basic functionality
in DFXP or in SmilText: text with start and end time. In fact, I
believe that should be the lowest possible profile of DFXP, too, so in
essence it becomes identical to srt. Then it's just a choice similar
to the one between atom and rss.

What I am more curious about is to create a specification for DFXP
where there is a mapping from DFXP constructs to HTML/CSS/JavaScript,
because that is what we will require to make an implementation in a
Web browser. This mapping is implicit in  Philippe's specification,
but needs to be made explicit in a document. It may well be the most
relevant document for the collaboration between the timed text WG and
the html WG.

> For the W3C to issue a recommendation that itself recommends the use of a
> non-standard caption-text format would, at the very least, appear rather
> awkward.

The current list is DFXP and srt. I don't see anything awkward about
it. The first is W3C politics and the second is Web dominance, to put
it blunt. Every Web user out there who would not see srt in that list
would believe the W3C is ignoring reality.

> Ease of authoring can’t really be used as a basis for its consideration.
>  John F made an excellent point the other night:  unless they’re just
> inserting occasional blocks of text, most people who write captions will not
> be writing them by hand with NotePad or TextEdit, they’ll use an application
> like MAGpie, Subtitle Workshop or a broadcast-level suite to create and
> format them.

There are more srt files available on the Web than DFXP files. In
fact, I have found it really difficult to find DFXP files in use in
the wild. A list of such would be really helpful for implementation
purposes. You'd be amazed how many people create srt files by hand or
with a simple application that is available for free from the
Internet. If you search for "subtitles" on Google, almost the whole
first page points to sites that provide subtitles in srt format or to
free software to create them, e.g.
I wasn't able to find a single site that offers DFXP or SmilText files.

> From my perspective, SmilText or profile of DFXP (or both) would be best as
> a recommended caption-text format.  That’s not to say we shouldn’t include
> SRT in the list, but I just don’t think it should be the primary
> recommendation.

There is no primary recommendation. Right now DFXP and srt stand on
the same line and both should be implemented. But an srt
implementation will be trivial and for DFXP we may still need to come
up with a common profile. So, there is work to be done and it will
definitely take longer to have more than just basic DFXP support.

Is there a reason that both SmilText and DFXP should be recommended?
The examples at http://www.w3.org/TR/SMIL3/smil-text.html look a lot
like some of the examples in DFXP.

Best Regards,
Received on Thursday, 18 February 2010 23:53:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:09 UTC