- From: David Singer <singer@apple.com>
- Date: Thu, 30 Aug 2012 11:14:08 -0700
- To: public-texttracks <public-texttracks@w3.org>
On Aug 30, 2012, at 3:06 , Simon Pieters <simonp@opera.com> wrote:
> On Thu, 30 Aug 2012 02:21:28 +0200, Glenn Maynard <glenn@zewt.org> wrote:
>
>>> key: |
>>> valueline
>>> valueline
>>> …
>>> .
>>>
>>
>> Also, &escapes; need to be allowed, so that "-->" can be escaped to
>> "-->". This is needed for single-line headers, too.
Why? We're in a block of text whose only parsing rule is that it terminates in a blank line. What am I missing?
>> Other than that
>> one oddity, however, this format requiers no escaping except for prefixing
>> backslashes, and unescaping can be as simple as "if the line begins with a
>> backslash, remove it".
>
> OK, now this syntax is becoming so horrible I don't know what to make of it. Please, let's take a step back and think again. We don't need to put everything between the "WEBVTT" and a blank line. We can have cue-like blocks for multiline things, e.g.:
>
> WEBVTT
> language: fr
> kind: subtitles
>
> STYLE
> #foo { color:green }
> i { font-family:serif }
>
> foo
> 00:00:00.000 --> 00:00:05.000
> testing <i>testing</i>
>
>
> This is backwards compatible!
Alas, it ain't. Existing parsers will try to treat
> STYLE
> #foo { color:green }
> i { font-family:serif }
as the first cue.
> No escapes needed! It doesn't support embedding "-->", but I'd rather change the parser to only be aggressive about "-->" after the first real cue than to support &escapes; in metadata values.
Right, I agree.
I think the following is equally readable (ignoring whether STYLE is ALL CAPS or not, and not really considering how one applies styles to cues)
WEBVTT
language: fr
kind: subtitles
STYLE: |
#foo { color:green }
i { font-family:serif }
.
00:00:00.000 --> 00:00:05.000
<c.foo>testing <i>testing</i></c.foo>
>
> --
> Simon Pieters
> Opera Software
David Singer
Multimedia and Software Standards, Apple Inc.
Received on Thursday, 30 August 2012 18:14:41 UTC