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: Simon Pieters <simonp@opera.com>
Date: Sun, 02 Sep 2012 09:51:18 +0200
To: "Glenn Maynard" <glenn@zewt.org>
Cc: "Ian Hickson" <ian@hixie.ch>, "David Singer" <singer@apple.com>, public-texttracks <public-texttracks@w3.org>
Message-ID: <op.wjzz3seuidj3kv@simons-macbook-pro.local>
On Sat, 01 Sep 2012 00:12:36 +0200, Glenn Maynard <glenn@zewt.org> wrote:

> On Fri, Aug 31, 2012 at 2:53 AM, Simon Pieters <simonp@opera.com> wrote:
>
>>  How does this represent blank lines?  Editing software should allow  
>> people
>>> to paste in CSS, and when they come back to it later, show the original
>>> text they entered in its original format, without blank lines stripped.
>>>
>>
>> The proposed pipe-dot-backslash-and-entity-**escaped syntax doesn't
>> handle that, either, AFAICT. It requires that you change all blank  
>> lines to
>> lines with a backslash (or remove the blank lines). In the syntax  
>> above, it
>> would require you to remove all blank lines.
>
>
> Sure it does.  The editor's parser removes them, and the code that saves
> the file adds them; editing software wouldn't show the backslash escapes.
> If you paste in CSS, then reload the file from disk and copy it back out,
> you'll get the exact same text you pasted in, ease-of-reading newlines  
> and
> all.

Well, if we're reasoning about software allows editing an arbitrary style  
sheet and hides the underlying syntax from the user, the editor can  
serialize the style sheet as a data: URL and put it in an @import.

The raw syntax should be easy to use and learn for people who hand-author  
with the raw syntax.

> I don't object to using a blank line as a terminator instead of a period,
> as long as it doesn't place odd restrictions on the contents of the  
> string
> (such as "no blank lines" or "no -->").

You can represent those in a data: URL.

> It's not 100% compatible with the
> current parser,

Why not?

> which the format we're proposing is intended to be, but if
> it's not too late to change the parser in that way then that's fine.
> Backslash--or whatever--escapes could easily be used in this scheme too.
> It would be needed in two situations instead of three, since "." wouldn't
> need escaping (only blank lines and lines starting with the escape
> character itself would need it).

I'd prefer if there wasn't any escaping at all.

>>>  I believe the point of the "-->" special case (parser step 14) is to
>>> tolerate when people omit the post-header blank line, eg.
>>>
>>> WEBVTT
>>> 00.000 --> 05.000
>>> ...
>>>
>>
>> It was added to the spec because I found by researching SRT that people
>> often forget a blank line *between* cues. It has not been shown that the
>> above pattern is a common one (since SRT doesn't have a header). I can
>> imagine that the above will be common for WebVTT, though. It doesn't
>> necessarily follow that it will be common to forget a blank line  
>> between a
>> multiline metadata value and the following cue.
>
>
> Step 14 executes before cues, not between them.

Yes, it was added everywhere in the parser for consistency, I believe.

> Anyway, again, I'd be
> happy if that step was changed so it doesn't trigger in the middle of a
> header, which I think would eliminate the need for escaping "--&gt;"  
> within
> header data.  Step 14 as it is right now is going to give "-->" headaches
> to *anything* placed before cues.

I'm OK with that.

-- 
Simon Pieters
Opera Software
Received on Sunday, 2 September 2012 07:52:05 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 8 May 2014 13:18:51 UTC