W3C home > Mailing lists > Public > public-texttracks@w3.org > September 2012

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 27 Sep 2012 11:26:05 +1000
Message-ID: <CAHp8n2n9eZAJdbNjLT4LnTW9D-J_h5ryZNjZm9S3zBpAJk6f9A@mail.gmail.com>
To: David Singer <singer@apple.com>
Cc: Simon Pieters <simonp@opera.com>, public-texttracks <public-texttracks@w3.org>
On Thu, Sep 27, 2012 at 8:45 AM, David Singer <singer@apple.com> wrote:
> On Sep 26, 2012, at 0:40 , Simon Pieters <simonp@opera.com> wrote:
>> On Tue, 25 Sep 2012 23:54:48 +0200, David Singer <singer@apple.com> wrote:
>>> On Sep 24, 2012, at 7:28 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>>>> In any case: I'm going to use file-wide metadata for the CEA-608/708
>>>> conversion document [1]. I'm going to follow what was last discussed
>>>> with Simon, except I don't really know when to end the multi-line
>>>> value, so I chose a random "##" as the character sequence to end it
>>>> (happy for any better suggestions). I preferred this as more obvious
>>>> than a single ".".
>>> roughly why I suggested [[ to open and ]] to close (it's more visually noticeable, and is like CDATA) :-).  Not a ditch worth dying in, as long as we choose a line that is unlikely in what we want to embed (notably CSS).
>>>> I'm fully aware that the WebVTT spec itself needs not to say anything
>>>> about this - it will not break browsers in any case. It would,
>>>> however, be better if we could change the spec to regard the
>>>> multi-line values that may have empty lines in them not as broken
>>>> cues, but as part of the header. We could define - as Simon said -
>>>> anything between the "WEBVTT" magic string and the first successfully
>>>> parsed cue as "header".
>>> ...or we could ban blank lines in the header (none of our use-cases require them, after all), or escape them (or a combination).
>> If the use cases don't require blank lines, we can use a blank line to end a multi-line header.
> ouch.  can we use the blank line, as now, to end the headers?
>  you seem to want to make it possible to mix headers and cues, which means we have to have a more complex way to tell them apart, and rules not to put headers after cues, and I am not sure at all why.  can you explain?

I thought we had agreed that we wanted to allow blank lines in
multi-line metadata values (in particular to more nicely format CSS
styles). Thus, a blank line shouldn't end the headers, but instead the
first validly parsed cue should.

Received on Thursday, 27 September 2012 01:26:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:20 UTC