On Wed, Aug 11, 2010 at 11:45 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 15:09:34 +0200, Silvia Pfeiffer <<a href="mailto:silviapfeiffer1@gmail.com" target="_blank">silviapfeiffer1@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
HTML and CSS have predefined structures within which their languages grow<br>
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<br>
with in-built extensibility, which WebSRT does not have.<br>
</blockquote>
<br></div>
The parser has the "bad cue loop" concept for ignoring supposedly bogus lines. Seems extensible to me.</blockquote><div><br></div><div><br></div><div>Hmm, that's for ignoring lines that don't match the "-->" pattern. It could work: ignore anything that's inside a WebSRT file and not a cue.</div>
<div><br></div><div>I tend to think of caption files as composed of the following broad components:</div><div>* header-data that is information that applies to the complete file, which tends to be setup data (such as language, charset, stylesheet link etc) and metadata (name-value pairs)</div>
<div>* a list of cues, which have their own structure:</div><div> ** start and end time</div><div> ** per-cue header-type data such as more setup data, positioning, text size etc</div><div> ** the cue text itself (in various structured formats, potentially with time markers for roll-on presentation)</div>
<div>* comments that can be made at any location</div><div><br></div><div>As long as we can make sure we're extensible within these broader areas, I *think* we should be ok.</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">
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>
<br>
They don't have their own variant of SRT - they only have their own parsers.<br>
</blockquote>
<br></div>
That comes down to the same thing in my opinion. This is like saying browsers did not all have their own variant of HTML4.</blockquote><div><br></div><div>From an author's point of view, they were not writing multiple different Web pages, but only trying to accommodate the quirks of each browser in one page. So, no, I wouldn't regard them as having different versions of HTML4.</div>
<div><br></div><div><br></div><div><br></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">
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<br>
<a href="http://en.wikipedia.org/wiki/SubRip#SubRip_text_file_format" target="_blank">http://en.wikipedia.org/wiki/SubRip#SubRip_text_file_format</a> . They all<br>
interoperate on the basic SRT format. But they don't interoperate on the<br>
WebSRT format. That's why WebSRT has to be a new format.<br>
</blockquote>
<br></div>
By that reasoning HTML5 would have had to be a new format too. And CSS 2.1 as opposed to CSS 2, etc.</blockquote><div><br></div><div>They interoperate by their sheer structure. It has been made sure that old browsers will ignore the new additions because there is a structured means to grow theres. So, no, I believe they are different cases.</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">
(And if they really just take in text like that they should at least run<br>
some kind of validation so not all kinds of garbage can get in.)<br>
</blockquote>
<br>
That's not a requirement of the "spec". It's requirement is to render<br>
whatever characters are given in cues. That's why it is so simple.<br>
</blockquote>
<br></div>
But it is not so simple because various extensions are out there in the wild and are used so the concerns you have with respect to WebSRT already apply.</blockquote><div><br></div><div>There are two version out there: the plain ones without markup and the ones with <i>,<b>,<u> and <font>. Nothing else exists. Those could be called quirks of the same format. I would prefer if SRT meant only the stuff without any markup at all, which is supported by everyone who supports SRT. The thing is, WebSRT isn't even backwards compatible with the quirky SRT extension: it doesn't support <u> and <font>. So, it's neither backwards nor forwards compatible.</div>
<div> </div><div><br></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">
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.<br>
</blockquote>
<br></div>
At least with the copy approach you would still see something in your SRT environment. The <ruby> bits would just be ignored or some such.<br></blockquote><div><br></div><div>Preferably, I would be using a captioning application which will make me aware that I am just now adding features that the format the I used for saving doesn't support. So it gives me the choice of either losing those features or upgrading to the better format. It's what all text processors do, too, so people are used to it. And they know to stick to the more capable formats.</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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><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">
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>
Actually that is not true. There is only one approach to parsing in Ian's proposal.<br>
</blockquote>
<br>
A the moment, cues can have one of two different types of content:<br>
(see <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#syntax-0" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#syntax-0</a><br>
<br></div>
[...]<div class="im"><br>
<br>
So that means in essence two different parsers.<br>
</div></blockquote>
<br>
Per the parser section there is only one. See the end of<br>
<br>
<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#parsing-0" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#parsing-0</a></blockquote><div><br></div><div>
Yeah, I think there's something missing in the spec.</div><div><br></div><div>Cheers,</div><div>Silvia.</div><div> </div></div>