I forgot to send this to the list.<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Silvia Pfeiffer</b> <span dir="ltr"><<a href="mailto:silviapfeiffer1@gmail.com">silviapfeiffer1@gmail.com</a>></span><br>
Date: Sat, Jul 24, 2010 at 10:00 PM<br>Subject: Re: [whatwg] Timed tracks for <video><br>To: Paul Ellis <<a href="mailto:paul@ellisfoundation.com">paul@ellisfoundation.com</a>><br><br><br><div><div></div><div class="h5">
On Sun, Jul 25, 2010 at 2:04 PM, Paul Ellis <span dir="ltr"><<a href="mailto:paul@ellisfoundation.com" target="_blank">paul@ellisfoundation.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div><div class="gmail_quote">On Sat, Jul 24, 2010 at 5:49 PM, Silvia Pfeiffer <span dir="ltr"><<a href="mailto:silviapfeiffer1@gmail.com" target="_blank">silviapfeiffer1@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On Sun, Jul 25, 2010 at 6:57 AM, Paul Ellis <span dir="ltr"><<a href="mailto:paul@ellisfoundation.com" target="_blank">paul@ellisfoundation.com</a>></span> wrote:<br></div><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div>On Fri, Jul 23, 2010 at 6:54 AM, Henri Sivonen <span dir="ltr"><<a href="mailto:hsivonen@iki.fi" target="_blank">hsivonen@iki.fi</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>
<div>On Jul 23, 2010, at 08:40, Ian Hickson wrote:<br></div></div><div>
> - Keep implementation costs for standalone players low.<br>
<br>
I think this should be a non-goal. It seems to me that trying to cater for non-browser user agents or non-Web uses in Web specs leads to bad Web specs. I think by optimizing for standalone players WebSRT falls into one of the common traps for Web specs. I think we should design for the Web (where the rendering is done by browser engines).<br>
</div></blockquote><div><br>I disagree that this should be a non-goal. Making it harder for content to be portable between the web and the non-web (standalone players, hardware devices, etc) will definitely stifle the adopting of WebSRT. There is already a significant ecosystem (players, creation tools, and content) around SRT that could easily be leveraged to make WebSRT successful.<br>
</div></div></blockquote></div><div><br><br>Everyone I have spoken to in this ecosystem recommended against extending SRT and recommended either picking one of the more capable existing formats (in particular ASS or the new AS6 which is in development) or - if that wasn't possible - recommended creating a proper format for the Web that can then be supported in its own right. I think if we have a mixed set of .srt files out there, some of which are old-style srt files (with line numbers, without WebSRT markup) and some are WebSRT files with all the bells and whistles and with additional external CSS files, we create such a mess for that existing ecosystem that we won't find much love.<br>
</div></div></blockquote></div><br></div></div>My comment was more generally about how we shouldn't completely ignore the benefits of adopting/extending existing popular solutions in such a way that there is some interoperability with the non-web. Through my work at DivX I have had a fair amount of exposure to various subtitle formats and the whole ecosystem (creation tools, content, software players, CE, etc) needed for a format to be successful. I wouldn't ever argue that SRT is an elegant format, but you also can't argue that it doesn't work in the ecosystem today. SSA/ASS is is a relatively robust subtitle format and is probably the only other format that has comparable support throughout the ecosystem as SRT.<br>
</blockquote></div><br><br></div></div>There is no issue with any of this. SRT is indeed successful. Also, it is indeed important to look at existing formats. I once held the opinion that we should support SRT as one of the most basic formats and DFXP as a highly capable format. I still don't mind about supporting SRT, but it's obviously not sufficient. Also, for our purposes, DFXP seems not to work. ASS/SSA was deemed too complex and incompatible with CSS. Thus, the creation of a new format was pursued.<br>
<br>WebSRT is a suggestion for a new format and one reason for its creation was that it would keep implementation costs for standalone players low because it can build on existing SRT infrastructure. I simply doubted whether it actually meets this goal, while Henri even more fundamentally doubted whether this is a valid goal. I've heard previously that whenever the W3C has tried to create a format that is also usable outside the Web, the design decisions that were made because of trying to make it work outside the Web have always turned out to be poor decisions. I don't have examples (maybe somebody else has?), but I can believe that trying to serve two masters is never a good idea - you might end up not serving either.<br>
<br><br>
</div><br>