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

Re: metadata in the VTT file header, re-starting the conversation

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 23 Feb 2012 09:05:29 +1100
Message-ID: <CAHp8n2mMc0QMJW7qYg2eMJ2vRSsYUaLsSgdtU-UeMCOHPaUKDQ@mail.gmail.com>
To: Ralph Giles <giles@mozilla.com>
Cc: David Singer <singer@apple.com>, "public-texttracks@w3.org" <public-texttracks@w3.org>
On Thu, Feb 23, 2012 at 8:53 AM, Ralph Giles <giles@mozilla.com> wrote:
> Hash: SHA1
> On 22/02/12 12:29 PM, David Singer wrote:
>> well, I was dividing the world into cue and non-cue, and calling
>> all the latter meta-data.  sorry if that confused…
> Fair enough.
> So it seems like we have two extension points. (1) We can put lines of
> additional data between the WEBVTT filetype identification line and
> the first double-newline. (2) we can define a more general extension
> method like Ian's 'COMMENT -->' stanzas.
> The first option seems uncontroversial, so I think we should just
> agree on and implement a key-value syntax for it. Parsers, and even
> the initial spec can easily skip this data.
> The second is more difficult. Looking at the use cases, the real
> advantage I see to have something beyond key-value lines is the
> ability to embed something like css without having to reformat it. But
> if I put the requirement like that, having to avoid the
> caption-closing double-newline inside the content is problematic. So I
> think if we do this we
> need a real quoting mechanism, something like David's '[[ ... ]]'
> proposal, but as a top-level parser token. And while that's not a
> character sequence which appears in css, we probably also want an
> escape mechanism in case someone does need to embed such a thing. As
> such, that's a much more invasive change. Is that worthwhile just to
> make multiline data attachments more readable?

Doesn't that essentially mean the introduction of a means of
commenting out stuff?

Received on Wednesday, 22 February 2012 22:06:16 UTC

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