On Mon, Sep 13, 2010 at 5: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><div></div><div class="h5">On Sat, 11 Sep 2010 01:27:48 +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, Sep 10, 2010 at 11:00 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 Thu, 09 Sep 2010 15:08:43 +0200, Silvia Pfeiffer<br>
<<a href="mailto:silviapfeiffer1@gmail.com" target="_blank">silviapfeiffer1@gmail.com</a>> wrote:<br>
<br>
 On Wed, Sep 8, 2010 at 9:19 AM, Ian Hickson <<a href="mailto:ian@hixie.ch" target="_blank">ian@hixie.ch</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, 23 Jul 2010, Philip Jägenstedt wrote:<br>
<br>
If we must have both kind=subtitles and kind=captions, then I'd suggest<br>
> making the default subtitles, as that is without a doubt the most<br>
common<br>
> kind of timed text. Making captions the default only means that most<br>
> timed text will be mislabeled as being appropriate for the HoH when it<br>
> is not.<br>
<br>
Ok, I've changed the default. However, I'm not fighting this battle if it<br>
comes up again, and will just change it back if people don't defend<br>
having<br>
this as the default. (And then change it back again if the browsers pick<br>
"subtitles" in their implementations after all, of course.)<br>
<br>
Note that captions aren't just for users that are hard-of-hearing. Most<br>
of<br>
the time when I use timed tracks, I want captions, because the reason I<br>
have them enabled is that I have the sound muted.<br>
<br>
<br>
</blockquote>
Hmm, you both have good points. Maybe we should choose something as the<br>
default that is not visible on screen, such as "descriptions"? That would<br>
avoid the issue and make it explicit for people who provide captions or<br>
subtitles that they have to make a choice.<br>
<br>
</blockquote>
<br>
If we want people to make an explicit choice, we should make kind a<br>
required attribute and make browsers ignore <track>s without it. (I think<br>
subtitles is a good default though.)<br>
</blockquote>
<br>
<br>
<br>
I think you misunderstood - my explanation probably wasn't very good. I'm<br>
looking at it from the authoring POV.<br>
<br>
What I meant was: if I author a text track that is supposed to be visible on<br>
screen as the video plays back and if we choose either @kind=subtitle or<br>
@kind=caption as the default, then I don't have to really think through<br>
about what I authored as it will be displayed on screen. This invites people<br>
to not distinguish between whether they authored subtitles or captions,<br>
which is a bad thing, because a deaf user may then get tracks with the wrong<br>
label and expectations. If, however, we choose as a default something that<br>
is not visible on screen, e.g. @kind=description or @kind=metadata, then the<br>
author who wants their text track to be visible on screen has to give it a<br>
label, i.e. make an explicit choice between @kind=subtitle and<br>
@kind=caption. I believe this will lead to more correctly labeled content. I<br>
am therefore strongly against default labeling with either subtitle or<br>
caption. We could make @kind a required attribute instead as you are saying.<br>
</blockquote>
<br></div></div>
OK, I think we mostly agree. Any default will sometimes be wrong, so to not have to choose between subtitles and captions, I'd still really prefer if specific HoH-tags like <sound> can be shown or hidden depending on user preference. I think that would lead to more content actually being written for HoH users, as it doesn't requiring maintaining 2 different files.</blockquote>

<div class="im"><br><br>Ah, you are talking about some kind of CSS marker for the audio events that are marked up in a caption file and that could just simple be "display: none" if they are viewed as a subtitle. Interesting idea... not sure that matches with the current spec though.<br>

 <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">
Does it matter that they aren't conformant if they work<br>
anyway?<br>
</blockquote>
<br>
<br>
The ones on the wrong charset won't work, at least not without us<br>
introducing specific handling for it - which is incidentally specific<br>
handling that non-Web applications won't get, so they are still left out in<br>
the rain. Think of a new standalone application that was developed just for<br>
WebSRT and only deals with UTF-8. It will not deal well with those legacy<br>
files.<br>
</blockquote>
<br></div><br>
Requiring UTF-8 and not requiring UTF-8 both has its downsides. I think that handling charset as an attribute on <track> isn't very difficult, but if there are SRT-incompatible changes for other reasons (e.g. a header) then I think we should go back to always requiring UTF-8.</blockquote>

<div><br><br>I'm very happy to always require UTF-8, in fact, I would prefer it. For me it's just another argument to break with history and have WebSRT stand on its own without having to worry about 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;"><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">
 many new files will not play in the software created for the old spec.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
As long as we don't add a header, the files will play in most existing<br>
software. Apart from parsers that assume that SRT is plain text (and thus<br>
would be unsuitable for much existing SRT content), what kind of breakage<br>
have you found with WebSRT-specific syntax in existing software?<br>
<br>
</blockquote>
<br>
I think we need to add a header - and possibly other things in the future.<br>
Will we forever have the SRT restrictions hold back the introduction of new<br>
features into WebSRT?<br>
</blockquote>
<br></div>
Yes, if we extend SRT we can't break compatibility. However, it seems that all the extensibility needed already exists, as arbitrary tag names are handled by the parser.</blockquote><div><br>Your analysis of what format for headers we can introduce without breaking old SRT files speaks against that. Whatever extensions we introduce beyond what we currently have will break compatibility with some and increasingly more old SRT parsing software. Not to speak of format compatibility, which is already a non-given.<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">
 None is allowed today, but it would be relatively straight-forward to<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">
introduce metadata before the cues (or even in between the cues). For<br>
example, we could add defaults:<br>
<br>
 *<br>
 DEFAULTS<br>
 L:-1 T:50% A:middle<br>
<br>
 00:00:20,000 --> 00:00:24,400<br>
 Altocumulus clouds occur between six thousand<br>
<br>
 00:00:24,600 --> 00:00:27,800<br>
 and twenty thousand feet above ground level.<br>
<br>
We could add metadata (here using a different syntax that is similarly<br>
backwards-compatible with what the spec parser does today):<br>
<br>
</blockquote>
<br>
<br>
  @charset --> win-1252<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 @language --> en-US<br>
<br>
 00:00:20,000 --> 00:00:24,400<br>
 Altocumulus clouds occur between six thousand<br>
<br>
 00:00:24,600 --> 00:00:27,800<br>
 and twenty thousand feet above ground level.<br>
<br>
<br>
<br>
</blockquote>
When I read the following:<br>
"A WebSRT file body consists of an optional U+FEFF BYTE ORDER MARK (BOM)<br>
character, followed by zero or more WebSRT line<br>
terminators<<br>
<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-line-terminator" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-line-terminator</a><br>


>,<br>
<br>
followed by zero or more WebSRT<br>
cues<<br>
<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-cue" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-cue</a><br>
><br>
<br>
separated<br>
from each other by two or more WebSRT line<br>
terminators<<br>
<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-line-terminator" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-line-terminator</a><br>


>,<br>
<br>
followed by zero or more WebSRT line<br>
terminators<<br>
<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-line-terminator" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-line-terminator</a><br>


><br>
<br>
."<br>
then that doesn't imply for me that we can add anything in front of the<br>
WebSRT cues without breaking the spec, or that we can define cues that are<br>
not time ranges around the "-->" sign.<br>
<br>
</blockquote>
<br>
The parsing algorithm simply skips over things it doesn't recognize,<br>
that's why adding basically any new syntax in between cues wouldn't break<br>
existing WebSRT parsers.<br>
</blockquote>
<br>
<br>
Legacy SRT parsers are not required to do so and even if they are actually<br>
implemented to deal with this situation, it's a dangerous assumption. We may<br>
as well write into the syntax description of WebSRT that any line that<br>
doesn't match the syntax description has to be ignored, which then has the<br>
effect that every single file in the world is a valid WebSRT file.<br>
</blockquote>
<br></div></div>
You're right, we shouldn't go around adding stuff before or between the cues just because the WebSRT parser allows it unless we also make sure that most legacy SRT parsers will handle it.<br>
<br>
(Making anything valid makes the syntax useless, though.)</blockquote><div><br>That will seriously inhibit extensibility for WebSRT. I don't think we can and should need to worry about legacy SRT parsers - and we can do that if we make WebSRT a new format.<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">
Allowing anything as part of the syntax is a bit<br>
dangerous though, as most unrecognized stuff between cues are likely<br>
broken cues. Validators should warn about it, not treat it as a comment.<br>
<br>
</blockquote>
<br>
I wasn't aware of the effect of the standardised parsing algorithm for<br>
WebSRT allowing "broken cues" to be dealt with. This will effectively mean<br>
that a parser will be required to parse all files that it is given from<br>
beginning to end and discard all non-conformant lines - even if that file<br>
may be a 100GB large movie file. In this case, I would really recommend that<br>
we put a magic identifier at the beginning of Web SRT files so we can be<br>
sure that the intention of the file was to be a WebSRT file. Let's have the<br>
string "WebSRT" at the beginning of the files.<br>
</blockquote>
<br></div>
That's a good point. I don't suppose it's a huge problem in practice that errors can't be detected until EOF, but it's certainly not a desirable feature. To maintain some sanity, we probably ought to either require the correct MIME type or require the correct magic bytes. From the <video> MIME type debacle, I think I slightly prefer magic bytes to be checked by the parser.<br>


<br>
I've also argued for the inclusion of metadata, so I'm beginning to warm up to the idea of adding a header beginning with "WebSRT" or some such. If we do this, no existing SRT content can be reused, but we can still try to make it possible for WebSRT files to be reusable in desktop applications, by keeping the syntax highly compatible so that the same parser can be used for both without a mode switch.</blockquote>

</div><br>Sounds good to me. I'm sure browsers would find a way to have old SRT files slip through the cracks, but that's not what we should be specifying for. SRT could IMHO be a second format to support in <track> elements, but WebSRT should be the baseline.<br>

<br>So, thinking about that header: from your analysis of the existing files: did you have many starting with @.. ?<br><br>I'd be happy for the name-value pairs spec that Ian mentioned, which could then lead to something like the following as header:<br>

<br>WebSRT<br>@language --> en-US<br>@kind --> subtitle<br>@cueformat --> plain/minimal/metadata<br>@author --> Frank, Charlie, Anna<br>@date --> 20th September 2010<br>@copyright --> WGBH, 2010<br>@license --> CC-BY-SA, <a href="http://creativecommons.org/licenses/by-sa/3.0/">http://creativecommons.org/licenses/by-sa/3.0/</a><br>

<br>Further, with your analysis, it seemed like the following could be acceptable for comments:<br><br>// Lines starting with // are comments<br><br>I'm sure I've forgotten some stuff, but these seemed immediately the most important.<br>

<br>Cheers,<br>Silvia.<br><br>