On Fri, Aug 20, 2010 at 10:53 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><div></div><div class="h5">On Wed, 18 Aug 2010 00:42:04 +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 Thu, Aug 12, 2010 at 6:09 PM, Philip Jägenstedt <<a href="mailto:philipj@opera.com" target="_blank">philipj@opera.com</a>>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 it<br>
works.<br>
</blockquote>
<br></div></div>
So, it seems clear that in order to use an HTML parser we have to sacrifice some features or make them more verbose.</blockquote><div><br>That sounds like there are multiple problems, when in fact we are only talking about the single use case of timestamps. All other requirements are met by the existing innerHTML parser. Is it really necessary to throw out all the advantages of re-using innerHTML just to avoid some extra markup for this single use case?<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;"> The whole of the WebSRT parser isn't very big or complicated, so I don't think implementation cost is a strong argument for reusing the HTML parser, especially since at least the timing syntax needs a separate parser.</blockquote>

<div><br><br>It's not just about implementation cost - it's also the problem of maintaining another spec that can grow to have eventually all the features that HTML5 has and more. Do you really eventually want to re-spec and re-implement a whole innerHTML parser plus the extra <t> element when we start putting <svg> and <canvas> and all sorts of other more complex HTML features into captions? Just because the <t> element is making trouble now? Is this really the time to re-invent HTML?<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"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


It's a bit more than just annoying to users. If there are automated<br>
processes involved that print that stuff on tape for example, you can burn<br>
through a lot of material and money before realising that your input files<br>
are "broken" and if you cannot get software support for the new files<br>
implemented, you may need to implement costly manual checking of the files.<br>
</blockquote>
<br></div></div>
SRT as it is today can and does contain broken timestamps, missing linebreaks and at least <i>, <b>, <u> and <font ...> markup, some of which is broken. If anyone is able to to rely on their input as being well-formed enough as to be put through automatic but costly processes, they'd have to have very good control of where their input comes from. I can't see how WebSRT would change that.</blockquote>

<div><br>I would indeed expect a fairly trusted relationship with the supplier. But assuming your supplier changes from SRT to WebSRT support in their captions. If they have two different file extensions, you will notice immediately and there is a trigger to actually start implementing WebSRT support. If they are the same file extension, that will cause the trouble I explained. If at least there was a version identifier in existing SRT, then we wouldn't have that trouble at all. But we've had this discussion.<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 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">
The core "problem" is that WebSRT is far too compatible with existing SRT<br>
usage. Regardless of the file extension and MIME type used, it's quite<br>
improbable that anyone will have different parsers for the same format. Once<br>
media players have been forced to handle the extra markup in WebSRT (e.g. by<br>
ignoring it, as many already do) the two formats will be the same, and using<br>
WebSRT markup in .srt files will just work, so that's what people will do.<br>
We may avoid being seen as arrogant format-hijackers, but the end result is<br>
two extensions and two different MIME types that mean exactly the same<br>
thing.<br>
</blockquote>
<br>
<br>
It actually burns down to the question: do we want the simple SRT format to<br>
survive as its own format and be something that people can rely upon as not<br>
having "weird stuff" in it - or do we not. I believe that it's important<br>
that it survives. WebSRT can have absolutely anything in it, including code<br>
and binary data, even if that stuff would not be interpreted in a browser,<br>
but handed on to the JavaScript API for a JavaScript routine to do something<br>
with it. It is a great extensible platform. But the advantage of SRT is that<br>
it is simple and reliably simple. We completely remove this option by<br>
stealing the format.<br>
</blockquote>
<br></div>
I've collected some statistics on existing SRT content that I intend to publish soonish. For now, I'll just note that >50% contain some form of markup. Adding to this various ways in which the files could be broken, it seems to me that SRT as deployed is neither really simple nor reliable. Private use of SRT is of course simple and reliable, but that will be true in the future too.<br>

</blockquote><div><br>Honestly, using the existing small mess around SRT as an excuse to turn it into a huge mess doesn't seem a good argument to me.<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>
Aside: WebSRT can't contain binary data, only UTF-8 encoded text.</blockquote><div><br>It sure can. Just base-64 encode it. I'm not saying it's a good thing, but if somebody really has an urge...<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"><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">
 Since browser vendors get all the benefits and none of the problems it<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">
would be a mistake to only listen to us, of course. It might be<br>
worthwhile<br>
contacting developers of applications like VLC, Totem or MPlayer and ask<br>
precisely how annoyed they would be if suddenly one day they had to tweak<br>
their SRT parser because of WebSRT.<br>
<br>
</blockquote>
<br>
<br>
Some of them have already spoken:<br>
<a href="http://forum.doom9.org/showthread.php?p=1396576" target="_blank">http://forum.doom9.org/showthread.php?p=1396576</a> "Extending SRT is a very<br>
bad<br>
idea" etc etc. Also, I've had feedback from other subtitle professionals<br>
that are also against extending SRT, the main reasons being to break<br>
existing working software environments.<br>
<br>
</blockquote>
<br>
The only way to really avoid messing with the ecosystem is to invent a<br>
completely new format. The choice is between something that won't work at<br>
all in non-browsers and something that will mostly work.<br>
</blockquote>
<br>
<br>
<br>
If you look at it realistically, we *are* inventing a completely new format.<br>
WebSRT only on the surface has some resemblance with SRT. When you dig<br>
deeper, it is a completely different format with different aims and<br>
applications. Yes, it covers all the SRT aims and applications, but it does<br>
so much more! Only some of it will work in non-browsers, others will utterly<br>
fail and will completely disrupt an already working ecosystem. I think it<br>
may even have a really bad effect if we introduce WebSRT as SRT in that<br>
authoring software will refrain from implementing support for the richer<br>
features in order not to disrupt the existing software ecosystem. In the end<br>
we might end up with a lot of unsupported features in WebSRT an no real<br>
progress. I much prefer having progress with a transition period with<br>
conscious decisions to support the extra features.<br>
</blockquote>
<br></div></div>
As long as WebSRT is similar enough to SRT that software developers can use the same parser for both, they will effectively become the same format.</blockquote><div><br>There is a difference between "being the same format" and "superceding". I believe strongly that WebSRT will supercede SRT. But if we make it the "same format", we simply inherit the mess that already exists. All those broken SRT files will continue to be broken WebSRT files. Just by taking over the format, we will not magically do away with the existing mess.<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 define WebSRT in a way that can handle >99% of existing content and degrade gracefully (enough) when using new features in old software, it seems reasonable to do. If lots of software developers cry foul, then perhaps we should reconsider. It seems to me, though, that actually researching and defining a good algorithm for parsing SRT would be of use to others than just browsers.<br>

</blockquote><div><br>How is that different from moving away from SRT. If everyone has to change their parsing of SRT to accommodate a new spec, then that is a new format.<br> <br><br>Cheers,<br>Silvia.<br><br></div></div>