File headers

On Wed, Oct 24, 2012 at 3:11 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> I'm now quite keen to use the following specification for multi-line cues:
> * if a metadata field has no value in the same line as the metadata
> field name, assume it's a multi-line metadata header
> * multi-line metadata headers ends when a line is parsed that only
> contains "##"
> * no empty lines are allowed within the multi-line metadata header (if
> people have a long CSS file with many empty lines to add, they should
> use external stylesheets through the @import directive)
>

Comments:

- If I have an editor that gives people a text box and lets them type in
CSS, and the user uses blank lines, they shouldn't disappear when they load
the file again later.  We should be able to store simple plain-text strings
without odd exceptions like "can't represent blank lines" or "can't
represent ## on a line by itself".  (Also, blank lines don't mean long
files; I use blank lines for readability in my stylesheets regardless of
size.  It's also not obvious to me that large stylesheets should
necessarily always be imports.)

- Currently, the suggested format means that if I edit a file that says

Author: Glenn
Language: en

and remove my name, giving

Author:
Language: en

then we end up with a header named "Author" with a value of "Language: en"
and everything that follows.  That's a confusing way to fail.  We discussed
a marker to indicate a multi-line header, eg. "Style: |", to help avoid
this.

- We still have the "-->" issue: current parsers will stop at the first
"-->", assuming it's a cue (http://dev.w3.org/html5/webvtt/#parsing step
14).  We should be able to represent "-->" in headers.  The options seem to
be:

1. Escape it, eg. "--&gt;".  That works, but it then means we need to
escape &, which is pretty annoying.
2. Change the parser's error handling to understands the header format, so
it only triggers when not within a real header.  I don't know if we can
still do this.  This doesn't affect existing WebVTT files, so there
shouldn't be a problem with web-compatibility.

-- 
Glenn Maynard