On Wed, Aug 11, 2010 at 9:49 PM, Anne van Kesteren <span dir="ltr"><<a href="mailto:annevk@opera.com">annevk@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 Wed, 11 Aug 2010 13:35:30 +0200, Silvia Pfeiffer <<a href="mailto:silviapfeiffer1@gmail.com" target="_blank">silviapfeiffer1@gmail.com</a>> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Wed, Aug 11, 2010 at 7:31 PM, Anne van Kesteren <<a href="mailto:annevk@opera.com" target="_blank">annevk@opera.com</a>> wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
While players are transitioning to WebSRT they will ensure that they do not break with future versions of the format.<br>
</blockquote>
<br>
That's impossible, since we do not know what future versions will look like and what features we may need.<br>
</div></blockquote>
<br>
If that is impossible it would be impossible for HTML and CSS too. And clearly it is not.</blockquote><div><br></div><div>HTML and CSS have predefined structures within which their languages grow and are able to grow. WebSRT has newlines to structure the format, which is clearly not very useful for extensibility. No matter how we turn this, the xml background or HTML and the name-value background of CSS provide them with in-built extensibility, which WebSRT does not have.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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">
I'm pretty sure that several will break. We cannot just test a handful of<br>
available applications and if they don't break assume none will. In fact,<br>
all existing applications that get loaded with a WebSRT file with extended features will display text with stuff that is not expected - in particular if the "metadata" case is used. And wrong rendering is bad, e.g. if it's<br>


part of a production process, burnt onto the video, and shipped to<br>
hearing-impaired customers. Or stored in an archive.<br>
</blockquote>
<br></div>
Sure, that's why the tools should be updated to support the standard format instead rather than each having their own variant of SRT.<br></blockquote><div><br></div><div>They don't have their own variant of SRT - they only have their own parsers. Some will tolerate crap at the end of the "-->" line. Others won't. That's no break of "conformance" to the basic "spec" as given in <a href="http://en.wikipedia.org/wiki/SubRip#SubRip_text_file_format">http://en.wikipedia.org/wiki/SubRip#SubRip_text_file_format</a> . They all interoperate on the basic SRT format. But they don't interoperate on the WebSRT format. That's why WebSRT has to be a new format.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
(And if they really just take in text like that they should at least run some kind of validation so not all kinds of garbage can get in.)</blockquote><div><br></div><div>That's not a requirement of the "spec". It's requirement is to render whatever characters are given in cues. That's why it is so simple.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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">
I don't think so. It just makes things more complex for authors (learn two formats,<br>
</blockquote>
<br>
I see that as an advantage: I can learn the simple format and be off to a<br>
running start immediately. Then, when I find out that I need more features, I can build on top of already existing knowledge for the richer format and can convert my old files through a simple renaming of the resources.<br>


</blockquote>
<br></div>
Or could you learn the simple format from a tutorial that only teaches that and when you see someone else using more complex features you can just copy and paste them and use them directly. This is pretty much how the web works.</blockquote>

<div><br></div><div>Sure. All I need to do is rename the file. Not much trouble at all. Better than believing I can just copy stuff from others since it's apparently the same format and then it breaks the SRT environment that I already have and that works.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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">
have to convert formats (i.e. change mime) in order to use new features<br>
(which could be as simple as a <ruby> fragment for some Japanese track)<br>
</blockquote>
<br>
If I know from the start that I need these features, I will immediately<br>
learn WebSRT.<br>
</blockquote>
<br></div>
But you don't.</blockquote><div><br></div><div>Why? If I write Japanese subtitles and my tutorial tells me they are not supported in SRT, but only in WebSRT, then I go for WebSRT. Done.</div><div><br></div><div> </div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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">
, more complex for implementors (need two separate implementations as to<br>
not encourage authors to use features of the more complex one in the less<br>
complex one), more complex for conformance checkers (need more code), etc.<br>
Seems highly suboptimal to me.<br>
</blockquote>
<br>
That's already part of Ian's proposal: it already supports multiple<br>
different approaches of parsing cues. No extra complexity here.<br>
</blockquote>
<br></div>
Actually that is not true. There is only one approach to parsing in Ian's proposal.</blockquote><div><br></div><div><br></div><div>A the moment, cues can have one of two different types of content:</div><div>(see <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#syntax-0">http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#syntax-0</a></div>

<div><br></div><div>"6. <span class="Apple-style-span" style="font-family: sans-serif, 'Droid Sans Fallback'; font-size: medium; line-height: 21px; ">The <dfn id="cue-payload" style="font-weight: bold; font-style: normal; cursor: pointer; ">cue payload</dfn>: either <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-cue-text" style="color: rgb(0, 0, 204); background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; background-position: initial initial; background-repeat: initial initial; ">WebSRT cue text</a> or <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-metadata-text" style="color: rgb(0, 0, 204); background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; background-position: initial initial; background-repeat: initial initial; ">WebSRT metadata text</a>."</span></div>

<div><br></div><div>So that means in essence two different parsers.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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">
My theory is: we only implement support for WebSRT in the browser - that it happens to also support SRT is a positive side effect. It works for the Web - and it works for the existing SRT communities and platforms. They know<br>


they have to move to WebSRT in the long run, but right now they can get away with simple SRT support and still deliver for the Web. And they have a<br>
growth path into a new file format that provides richer features.<br>
</blockquote>
<br></div>
This is the proposal. That they are the same format should not matter.</blockquote><div><br></div><div>It matters to other applications, see <a href="http://forum.doom9.org/showthread.php?p=1396576">http://forum.doom9.org/showthread.php?p=1396576</a> . We should tolerate that.</div>

<div> </div><div>Cheers,</div><div>Silvia.</div><div><br></div></div>