W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2010

[whatwg] On the subtitle format for HTML5

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 24 May 2010 12:04:41 +1000
Message-ID: <AANLkTimXBCQkcr1Clp8rCFZVBPkTMQVxBoYu4JKQPyvG@mail.gmail.com>
2010/5/24 Tab Atkins Jr. <jackalmage at gmail.com>:
> 2010/5/22 Carlos Andr?s Sol?s <csolisr at gmail.com>:
>> Hello, I've been writing lately in the WHATWG and WebM mail-lists and would
>> like to hear your opinion on the following idea.
>> Imagine a hypothetical website that delivers videos with subtitles that can
>> be chosen by the user. And also imagine there is the possibility of
>> downloading a file with the video, along with either the chosen subtitle
>> tracks, or all of them at once. The problems on multiple tracks I have
>> already discussed in another thread; this one deals mainly with subtitle
>> formats. There is still an issue on which format should be used for
>> subtitling in HTML5. As you might know, there are basic subtitle formats
>> that are formed by timed plain text and little else (like SRT or the
>> proposed WebSRT), and there are full-blown subtitle formats that allow for
>> extreme formatting and typesetting (like Advanced SubStation Alpha). The
>> basic subtitles have the advantage of being easily editable by hand, but
>> sacrificing capabilities that advanced formats allow with the cost of
>> harder-to-understand syntax. It would be a shame to drop advanced subtitles
>> from the HTML5 specs, but it would be bothersome if everybody is forced to
>> use a complex-to-write format. So a middle ground could be handy: allowing
>> WebSRT for the simple tasks, and using another format for advanced
>> typesetting. To put an example, ASSA allows to modify the text font, size,
>> border, shadow, scale, rotation, position, and some other properties; it
>> also allows movement of text, text animation, karaoke, and even some
>> vectorial graphing.
> There is little, if any, reason to bake most of that directly into the
> subtitle format. ?WebSRT just grabs all the necessary use-cases (size,
> karaoke, etc) and bakes them in, in approximately the simplest way
> possible. ?Then more advanced stuff can be done through existing
> technology. ?In a browser, you can do it with ordinary CSS. ?In other
> devices, they can either come up with their own way of doing things,
> or embed a CSS-compliant renderer and just use CSS like everyone else.
> ?The latter is probably going to prove to be the most popular, since
> you can just embed a modified webkit or similar into your device and
> be done with it.
>> But all of that could be achieved with HTML5 programming
>> on top of the WebSRT format (or whichever gets chosen). This, of course,
>> causes a pair of problems.
>> * The first one is that there would be no tools to edit HTML5 subtitles
>> specifically, forcing to make a type of subset which would have to be
>> standardized, plus an editor to be able to create such subtitles without
>> having to learn how to create a full-blown website.
>> * The second one is that media players that wanted to use such subtitles
>> would be forced to ship an HTML5 decoder. Most media players are NOT web
>> browsers, though, or based on one either. The only exceptions I remember are
>> media players built on top of XUL, like Songbird or Nightingale. But players
>> like WMP, WinAmp, VLC, Xine family, GStreamer family or MPlayer family would
>> be left out, since they have no need (and no time) to plug in a web browser
>> in a program that hasn't needed it.
> This is why you want the format as simple as possible, and then just
> layer existing technology on top of it. ?Simple devices that don't
> want to care about advanced styling don't have to; as long as they
> support the handful of things that WebSRT requires, they're good.
> ~TJ

I just came across this thread
http://forum.doom9.org/showthread.php?p=1397067 and found it a most
interesting read!
Particularly the comment of jiifurusu .

It seems the subtitling community is developing a replacement format
for ASS with advanced features beyond what WebSRT has. Wouldn't that
show there is a need for an exchange format with advanced features?

That new format seems to try and cater for high-end needs and lower
end needs. If we have to develop a new non-HTML-like format, wouldn't
it make sense to coordinate with those guys? In particular if the
community that we are trying to build upon by reusing SRT is actually
against extending SRT?

Received on Sunday, 23 May 2010 19:04:41 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:23 UTC