[whatwg] Timed tracks: feedback compendium

[Silvia Pfeiffer]

On Fri, Oct 22, 2010 at 10:18 PM, Simon Pieters <simonp at opera.com> wrote:
> On Fri, 22 Oct 2010 13:09:24 +0200, Philip Jägenstedt <philipj at opera.com>
> wrote:
>
>>> Using <!-- --> is a bad idea since the WebSRT syntax already uses -->. I
>>> don't see the need for multiline comments.
>>
>> Right. If we must have comments I think I'd prefer /* ... */ since both
>> CSS and JavaScript have it, and I can't see that single-line comments will
>> be easier from a parser perspective.
>
> Line comments seem better from a compat perspective (you wouldn't get
> commented out stuff appear as cues in legacy parsers).

Philip's research earlier from this thread was as follows:

; appears at the beginning of lines in 15/10000 files and most don't look
like they're intended as comments.

# appears at the beginning of lines in 244/10000 files and most don't look
like they're intended as comments.

/* only appears in 3/10000 files, so CSS-style comments might work, but
does add some complexity

// appears at the beginning of lines in 5/10000 files and most look like
that *are* intended as comments or are garbage, so it should work.

(data from OpenSubtitles sample)

which seems to support the choice of //.

I do wonder what the lines that start with ; or # contained though.



>>>>> Anyway, I agree that at least a magic header like "WebSRT" is needed
>>>>> because
>>>>> of the horrors of legacy SRT parsing.
>>>
>>> I don't see why we can't just consume the legacy and support it in
>>> WebSRT. Part of the point with WebSRT is to support the legacy. If we don't
>>> want to support the legacy, then the format can be made a lot cleaner.
>>
>> Did you read
>> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-October/028799.html>
>> and look at <http://ale5000.altervista.org/subtitles.htm>?
>
> Yes.
>
>
>> Do you think it's a good idea to make WebSRT an extension of ale5000-SRT?
>
> Yes. :-) We could remove stuff from ale5000-SRT if there isn't interop
> already and the relevant vendors agree to remove it from their impls.


We'd just be adding to the already existing mess. Actually, such a
choice will encourage people to invent and use whatever tags they
like, because that has been the tradition with SRT. What exists is a
mess. We add to the mess, disallowing some of the existing tags that
are in wide us. People ignore that - existing applications already
support them anyway. So, we will have to adapt with those existing
tags - eventually we end up with the ale5000-SRT mess. Honestly, not a
great idea.


>> My opinion is that it's not a very good idea, which of course we can
>> simplify some aspects of the format. For example, we don't need to allow
>> both , and . as the millisecond separator, and the time parsing in general
>> can be made more sane.
>
> Do you think browsers will support vanilla SRT (i.e. ale5000-SRT) as well?

Not browsers - at least not at first. But other applications do, and
many support a large amount of them. So, if we want to support legacy,
we have to bite the bullet - eventually.

Cheers
Silvia.