Re: File headers

On Sun, Mar 10, 2013 at 8:34 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> The intent is to allow a WebVTT editor, or serialization and parsing
>> library, to represent blank lines, so the header format doesn't have a
>> weird exception of not being able to represent something as basic as a
>> blank line.  I don't expect people hand-authoring WebVTT files to use this.
>>
>
> We can't exclude that possibility. I'd expect a lot of cut-and-paste
> authoring, which would totally break for CSS.
>

If you cut-and-paste a block of text into WebVTT containing blank lines
blindly, either way it's not going to work.  Giving a way to represent
blank lines doesn't make that problem any worse, it just gives a way to
avoid it.

 Author: Glenn
>>>> 00:11.000 --> 00:13.000
>>>> Hello
>>>>
>>>
>>> Wouldn't this end up being a cue in the current parser? So, this is a
>>> non-backwards compatible change?
>>>
>>
>> By recover, I mean that it would become a cue, just as it does today,
>> because the "digit ... -->" string doesn't lie in a multi-line header.
>>
>
> I'd prefer if we could define cues to require a blank line in front of
> them.
>

Cues are already defined that way.  That's #4 in "WebVTT file body": "two
or more WebVTT line terminators".  But, the parser tries to recover if you
forget.  That's what step 14 is about.

In this case, it would become a cue only if "Autor: Glenn" is accidentally
> detached from the rest of the header and turns into the identifier of the
> cue.
>

In today's spec, the above text is parsed as a cue, even though it violates
the file format spec.  (This doesn't change with this proposal; this would
still be parsed as a cue.  It's the example below that changes.)



>  This is the case it won't fully recover from, causing the first cue to
>>>> be dropped, which I think is fine:
>>>>
>>>> Author: |
>>>> Glenn
>>>> 00:11.000 --> 00:13.000
>>>> Hello
>>>>
>>>
>>> If there are no blank lines at all before this cue, it will be dropped
>>> currently, too.
>>>
>>
>> No, the current parser will recover this cue.  See step 14 and the
>> "already collected line" flag.  In this approach, the parser would now drop
>> the cue in the case of this authoring error.
>>
>
> Did you mean s/now/not/?
>

Nope.  With parsers based on today's spec, the above cue will be parsed as
a cue (even though it violates the file format spec).  With this approach,
it would be parsed as part of the header (eg. it wouldn't be parsed as a
cue).  This is the only situation (that I'm aware of) where this proposal
would result in different behavior than implementations based on the
current spec.


> I f there is not a single blank line before the cue in the header, then it
> should be dropped. I agree that step 14 is a problem. I think step 14
> should only be executed after an empty line has been parsed. That would
> solve the whole need for escaping --> . It does cause some files to fail
> that forgot the blank line, but I think that's a fair enough breakage.
>

The whole point (as I understand it) of step 14 is error recovery.  The
following is likely a predictable authoring error:

WEBVTT
00:11.000 --> 00:13.000
Hello

The parser is intentionally designed to recover from this error, so the
first cue isn't silently dropped.  (I'm not proposing to change that, only
to tighten it up, so it doesn't happen mid-multiline-cue.)


> Agreed. I'm concerned with both of these as backwards compatible but only
> for implementations that followed the current spec (apart from step 14 ;-).
>

The only backwards-incompatible changes are related to step 14 and
nonconforming content (I think!).

I'm sort of liking the HTML-escaping alternative more, though.  It's
completely backwards-compatible, and uses an escaping mechanism everyone
already understands and which is already used by WebVTT.

On Mon, Mar 11, 2013 at 5:00 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> It's really annoying to have to edit that as you're cutting and pasting. I
> think it will be the cause of a lot of issues.
>

Having a way to escape newlines doesn't introduce any new issues with
cutting and pasting that don't already exist.

On Mon, Mar 11, 2013 at 5:33 PM, David Singer <singer@apple.com> wrote:

> You can do those with two Style: lines.
>

I'd recommend headers not allow duplicate keys, like attributes in HTML.
If you want to import multiple stylesheets, use eg. "Style: sheet1.css,
sheet2.css".

-- 
Glenn Maynard