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

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

From: Ralph Giles <giles@mozilla.com>
Date: Wed, 22 Feb 2012 13:53:36 -0800
Message-ID: <4F4563E0.8010306@mozilla.com>
To: David Singer <singer@apple.com>
CC: "public-texttracks@w3.org" <public-texttracks@w3.org>
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?

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

Received on Wednesday, 22 February 2012 21:54:07 UTC

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