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

On Sun, 02 Sep 2012 11:31:13 +0200, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> I would prefer if we didn't have to escape anything.

OK, good. :-)

> But I also agree
> that pushing a header into a "broken cue" is rather fragile.

I don't understand what's fragile about it.

> I am in
> particular concerned that it might end up as a cue inside
> encapsulations that follow the parsing algorithm of WebVTT. E.g. say
> you're parsing a WebVTT file according to its structure to encapsulate
> them into WebM, then you would end up identifying the header until the
> first empty line, then identifying the cues. And as you identify a cue
> that you cannot give a time segment to (because there is none), you
> drop the cue on the floor. This means that a WebM encapsulation would
> always drop an inline style sheet.

The spec says to drop the header on the floor as well, so a WebM  
encapsulation that implements the current spec would drop an inline style  
sheet in the header as well.

> If we could extend the WebVTT parser to have, say
>
> WEBVTT
> END
>
> as the header and ignoring everything betwen WEBVTT and END, then we
> could do whatever in the header, including having blank lines.

It would not make any difference to existing parsers.

> It's
> not backwards compatible with the blank line mechanism, but it might
> not be too late to introduce something like this.

I don't see the benefit over not using the END marker. If we can make  
breaking changes, then certainly we can design something that doesn't need  
escaping. But we already have built-in extension points in the parser  
(per-file headers, cue-level blocks (can be per-file if we want), per-cue  
settings...) so we don't need to do breaking changes to the parser and  
still have a syntax that doesn't need escaping.

> Then we could have multi-line header fields with blank lines like this:
>
> WEBVTT
> language: fr
> kind: subtitles
>
> STYLE
> #foo { color:green }
> i { font-family:serif }
>
> END
>
> foo
> 00:00:00.000 --> 00:00:05.000
> testing <i>testing</i>

Existing parsers would drop the headers and the STYLE and END blocks on  
the floor and successfully parse the cue.

> Silvia.

cheers
-- 
Simon Pieters
Opera Software

Received on Sunday, 2 September 2012 11:16:59 UTC