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: David Singer <singer@apple.com>
Date: Thu, 27 Sep 2012 16:58:07 -0700
Cc: public-texttracks <public-texttracks@w3.org>
Message-id: <DA45E012-EF9C-4281-B0D8-BBA00B6A35F3@apple.com>
To: Simon Pieters <simonp@opera.com>

On Sep 26, 2012, at 23:14 , Simon Pieters <simonp@opera.com> wrote:

> On Thu, 27 Sep 2012 00:45:02 +0200, David Singer <singer@apple.com> wrote:
>>> 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?
> Why?
>> you seem to want to make it possible to mix headers and cues,
> No, I'm not interested in that at all.
>> 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?
> As soon as you've seen a cue, the header part of the file is over. I don't see why that's harder than ending the header part when seeing a blank line.
> I think a blank line is more aesthetically pleasing and more in line with the rest of the WebVTT syntax (cues are separated by blank lines) than "." or "]]" or "##".

OK, so a blank line is easily defined, easily seen, and easily escaped.  "Something that looks like the first cue" is not.  Yes, it's definable, but why? I think it substantially less aesthetic to have rules about character sequences that have to be escaped, than about (blank) lines that have to be escaped.  Your proposal would make some character sequences invalid in any attribute-value; whereas terminating the header block on a blank line has no such problem.

I am puzzled at both the complexity and the aesthetics here, honestly, and can't work out what's driving.

>>> language: en
>>> style:
>>> @import url(style.css);
>>> kind: subtitles
>>> 00:00:00.000 --> 00:00:05.000
>>> cue
> -- 
> Simon Pieters
> Opera Software

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Thursday, 27 September 2012 23:58:35 UTC

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