On Mon, Aug 23, 2010 at 6:55 PM, Philip Jägenstedt <span dir="ltr"><<a href="mailto:philipj@opera.com">philipj@opera.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Sat, 21 Aug 2010 01:32:49 +0200, Silvia Pfeiffer <<a href="mailto:silviapfeiffer1@gmail.com" target="_blank">silviapfeiffer1@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Aug 20, 2010 at 10:53 PM, Philip Jägenstedt <<a href="mailto:philipj@opera.com" target="_blank">philipj@opera.com</a>>wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, 18 Aug 2010 00:42:04 +0200, Silvia Pfeiffer <<br>
<a href="mailto:silviapfeiffer1@gmail.com" target="_blank">silviapfeiffer1@gmail.com</a>> wrote:<br>
<br>
 On Thu, Aug 12, 2010 at 6:09 PM, Philip Jägenstedt <<a href="mailto:philipj@opera.com" target="_blank">philipj@opera.com</a><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>wrote:<br>
<br>
Yeah, so the only conforming solution is probably to use CSS3<br>
transition-delay property. That may not be the most elegant solution, but<br>
it<br>
works.<br>
<br>
</blockquote>
<br>
So, it seems clear that in order to use an HTML parser we have to sacrifice some features or make them more verbose.<br>
</blockquote>
<br>
<br>
That sounds like there are multiple problems, when in fact we are only<br>
talking about the single use case of timestamps.<br>
</blockquote>
<br></div>
I was referring also to the voices markup which is made much more verbose.</blockquote><div><br>Yeah, but that one actually makes sense to be integrated with existing ways that class and CSS work.<br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

I don't expect that SVG, <canvas>, images, etc will ever natively be made part of captions. Rather, I would hope that the metadata state together with scripts is used. If we think that e.g. images in captions are an important use case, then WebSRT is not a good solution.<br>

</blockquote><div><br>I believe they will be. But since we are only looking at the ways in which captions and subtitles are used currently, we haven't accepted this as an important use case, which is fair enough. I am considering likely future use though, which is always hard to argue.<br>

<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If we allow arbitrary HTML and expect browsers to handle it well, it adds some complexity. For example, any videos and images in the cue would have to be fully loaded and ready to be decoded by the time the cue is to be shown, which I really don't want to implement the logic for. Simply having an iframe-like container where the document is replaced for each cue wouldn't be enough, rather one would have to create one document per cue during parsing and wait for all of those to finish loading before beginning playback. I'm not sure, but I'm guessing that amounts to significant memory overhead.<br>

</blockquote><div><br>I have to leave that discussion to others, since I don't know enough about how the plumbing used in browsers works together. My expectation was that most of the plumbing with innerHTML already exists and the loading/display of the cue will be in parallel to the video playback, so it won't hold back the main page, even if e.g. a img element cannot be loaded in time.<br>

<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Honestly, using the existing small mess around SRT as an excuse to turn it<br>
into a huge mess doesn't seem a good argument to me.<br>
</blockquote>
<br></div></div>
I'm just saying that SRT isn't a plain text format today and anyone who's able to assume it is can only do so because they control the input.<br>
<br>
Deployed SRT uses <i>, <b>, <font> and <u>. WebSRT adds <ruby>, <rt> and <1>...<infinity>, extensions which are very much in line with the existing format and already "works" in many players (in the sense that they are ignored, not rendered). I wouldn't call that a huge mess.</blockquote>

<div><br>And removes <font> and <u>. And adds a whole swag of other functionality, which are not in line with the existing format. Just picking a part of the WebSRT specification that may work if the software was written sanely isn't really a fair argument for compatibility. But anyway, I think at this stage we can only agree to disagree about whether SRT ad WebSRT are compatible. :-)<br>

<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 class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Aside: WebSRT can't contain binary data, only UTF-8 encoded text.<br>
</blockquote>
<br>
<br>
It sure can. Just base-64 encode it. I'm not saying it's a good thing, but<br>
if somebody really has an urge...<br>
</blockquote>
<br></div>
Sure, this would be a metadata track. Sites have no reason to offer download links to it, and if anyone gets hold of such a file it would quickly be evident that it's useless.</blockquote><div><br>After a user has seen the crap on screen. I'm just saying: it's a legal WebSRT file and really not compatible with any existing infrastructure for SRT.<br>

<br><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></div><div class="h5"></div></div></blockquote><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"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If we define WebSRT in a way that can handle >99% of existing content and<br>
degrade gracefully (enough) when using new features in old software, it<br>
seems reasonable to do. If lots of software developers cry foul, then<br>
perhaps we should reconsider. It seems to me, though, that actually<br>
researching and defining a good algorithm for parsing SRT would be of use to<br>
others than just browsers.<br>
<br>
</blockquote>
<br>
How is that different from moving away from SRT. If everyone has to change<br>
their parsing of SRT to accommodate a new spec, then that is a new format.<br>
</blockquote>
<br></div>
Not everyone has to change their parsers immediately, many will continue to work. However, if someone wants to support SRT in a compatible way, it's very helpful to have a spec, assuming that WebSRT is actually compatible enough with existing SRT content.<br>


<br>
This is quite similar to HTML4 vs HTML5. There are lots of mostly compatible HTML parsers, but HTML5 defines a single parsing algorithm, and slow convergence towards that is a good thing.<br></blockquote><div><br>No, no, no! It is not at all similar to HTML4 and HTML5. A Web browser cannot suddenly stop working for a Web page, just because it has some extra functionality in it. Thus, the HTML format has been developed such that it can be extended without breaking existing stuff. We can guarantee that no browser will break because that is the way in which the format has been specified.<br>

<br>No such thing has happened for SRT and there is simply no way to guarantee that all new WebSRT files will work in all existing SRT software, because SRT has not been specified as a extensible format and because there is no agreement between all parties that have implemented SRT support as to how extensions should be made.<br>

<br>We can introduce such a thing for WebSRT, but we cannot claim it for SRT.<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


If the SRT ecosystem is so fragile that it cannot tolerate any extension whatsoever, then we should stay far away from it. It just seems that's not the case.</blockquote><div><br>How do we know that everyone that uses SRT now really wants to use WebSRT instead and wants to take part in the new ecosystem that we are introducing? We make some pretty big assumptions about what everyone who is not a Web browser vendor wants to do with SRT. That doesn't make the existing SRT ecosystem fragile - but it makes it an existing environment that needs to be respected.<br>

<br>Cheers,<br>Silvia.<br><br>P.S. I do wonder if anyone other than us is still following this thread. ;-)<br>
</div></div>