Re: Metadata in the VTT file header (bug 15851), use cases (and a need to close this)

On Fri, Aug 31, 2012 at 2:53 AM, Simon Pieters <simonp@opera.com> wrote:

>  How does this represent blank lines?  Editing software should allow people
>> to paste in CSS, and when they come back to it later, show the original
>> text they entered in its original format, without blank lines stripped.
>>
>
> The proposed pipe-dot-backslash-and-entity-**escaped syntax doesn't
> handle that, either, AFAICT. It requires that you change all blank lines to
> lines with a backslash (or remove the blank lines). In the syntax above, it
> would require you to remove all blank lines.


Sure it does.  The editor's parser removes them, and the code that saves
the file adds them; editing software wouldn't show the backslash escapes.
If you paste in CSS, then reload the file from disk and copy it back out,
you'll get the exact same text you pasted in, ease-of-reading newlines and
all.

I don't object to using a blank line as a terminator instead of a period,
as long as it doesn't place odd restrictions on the contents of the string
(such as "no blank lines" or "no -->").  It's not 100% compatible with the
current parser, which the format we're proposing is intended to be, but if
it's not too late to change the parser in that way then that's fine.
Backslash--or whatever--escapes could easily be used in this scheme too.
It would be needed in two situations instead of three, since "." wouldn't
need escaping (only blank lines and lines starting with the escape
character itself would need it).

 I believe the point of the "-->" special case (parser step 14) is to
>> tolerate when people omit the post-header blank line, eg.
>>
>> WEBVTT
>> 00.000 --> 05.000
>> ...
>>
>
> It was added to the spec because I found by researching SRT that people
> often forget a blank line *between* cues. It has not been shown that the
> above pattern is a common one (since SRT doesn't have a header). I can
> imagine that the above will be common for WebVTT, though. It doesn't
> necessarily follow that it will be common to forget a blank line between a
> multiline metadata value and the following cue.


Step 14 executes before cues, not between them.  Anyway, again, I'd be
happy if that step was changed so it doesn't trigger in the middle of a
header, which I think would eliminate the need for escaping "--&gt;" within
header data.  Step 14 as it is right now is going to give "-->" headaches
to *anything* placed before cues.

-- 
Glenn Maynard