Hello, I've been writing lately in the WHATWG and WebM mail-lists and would like to hear your opinion on the following idea.<br><div class="gmail_quote"><br>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. 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.<br>
* 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.<br>
* 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.<br>
<br>Any ideas or suggestions?<br clear="all"><font color="#888888">- Carlos Solís<br>
</font></div>