- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 23 Feb 2012 09:05:29 +1100
- 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: > -----BEGIN PGP SIGNED MESSAGE----- > 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? Silvia.
Received on Wednesday, 22 February 2012 22:06:16 UTC