Re: File headers

On Tue, Apr 23, 2013 at 1:18 PM, Glenn Maynard <glenn@zewt.org> wrote:

>
> On Mon, Mar 18, 2013 at 1:39 PM, David Singer <singer@apple.com> wrote:
>
>>  agreed.  if we don't like escaping blank lines, don't have them. it's
>> no harder to remove them than it is to insert the escape.
>>
>
> I've explained why supporting blank lines is useful.  It's something the
> world will live with and tolerate if we force it on them, but the UX (or
> perhaps AX--authoring experience) will be poor.
>
> A) All headers are single-line.  Result: you want a short file-specific
>> style sheet, either write it on one line, or put it in a separate file.
>>
>
> Forcing people to write stylesheets on a single line is a painful option
> to consider.  In my opinion, the options are either 1: don't allow inline
> stylesheets of any kind, or 2: allow them and don't force them to be
> flattened to a single line.  If inline stylesheets are useful enough to
> support, they're useful enough to support without obfuscation.
>
>
>> C) Headers are multi-line, and blank lines and lines that emulate the
>> terminator are escaped.  Result: when you in-line something, you have to
>> look at it and maybe fix it up (or have a tool that does that
>> automatically).
>>
>
> Again, if you paste text into a WebVTT header that might contain blank
> lines, you will always have to fix it up.
>
> &escapes; are needed to allow the string --> anyway (I hope we're not
> seriously considering creating a file format that can't represent that
> series of characters in a header --> at all <--), and it means that when
> users enter text into a WebVTT editor, newlines don't obnoxiously disappear.
>
> On Tue, Mar 19, 2013 at 4:23 PM, David Singer <singer@apple.com> wrote:
>
> Right.  If we go with only single-line headers, and leave multi-line until
>> we Know How to Do It Right, can we still do inline CSS?  Yes, we can.  A
>> syntactically valid CSS file can have its line breaks replaced by other
>> whitespace.  (An invalid one might become valid, but that doesn't worry us.)
>>
>
> If we can't find a better method now, we won't in the future, since it'll
> only become exponentially harder as legacy data and parsers show up in the
> wild and the options become restricted.  I think in this case "we'll solve
> this later" means "we'll never do this at all", so let's make the right
> decision now while we can.
>


Agreed. And we need to move fast because once Mozilla ships WebVTT support,
usage will rise more quickly.

I see two options:

1. We don't allow blank lines in header fields - thus we will only have
external style sheets.

2. We tighten up the parser about how to identify the first cue.

I am prepared to go with 2 and break some backwards compatibility as this
stage. We could instead of identifying a cue after the first blank line,
only stop header parsing after the first *successfully* parsed cue after a
blank line. Could that work? How bad would the consequences be of braking
backwards compatibility at this stage?

We could further put the metadata in an explicit META section (similar to
NOTE) and thus more explicitly separate META from NOTE and other such
extensions that we're planning (e.g. we could explicitly do STYLE).

Silvia.