<div class="gmail_quote">On Fri, Jul 23, 2010 at 6:54 AM, Henri Sivonen <span dir="ltr"><<a href="mailto:hsivonen@iki.fi">hsivonen@iki.fi</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 class="im">On Jul 23, 2010, at 08:40, Ian Hickson wrote:<br></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>

</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> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Why karaoke and application-specific data? Those both seem like feature creep compared to the core cases of subtitles and captions.<br></blockquote><div><br>Completely agree. Even though subtitles/captions and karaoke are both essentially text synchronized to audio/video they are really completely different use cases. And Karaoke is a much less prominent use case on the web.<br>

<br>Paul Ellis<br><br></div></div><br>