Re: File headers

On Apr 23, 2013, at 2:48 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

> 
> 
> 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.

that's if we have only single-line values (fine by me also),

or if multi-line, escaped blank lines (which is fine by me), or sheets edited to remove blank lines (also fine).


> 
> 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?

why do we need to allow the lack of a blank line before the first cue, i.e. why are we scanning for the -> stuff in the header?  In HTML, this kind of thing is there because of old poorly-written yet still-parsed content.  If we don't allow such content to work from day one, this problem never arises, and then the scanning is much much easier (look only for a blank line).

> 
> 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).

true too.  I don't really mind which, except that having raised this ages ago when there was much room for flexibility, the flexibility is rapidly decaying.  we want to support this format not conceptually but practically, and this uncertainty is eating away at that.

> 
> Silvia.
> 

David Singer
Multimedia and Software Standards, Apple Inc.