Re: Metadata in the VTT file header (bug 15851), use cases (and a need to close this)

On Fri, 31 Aug 2012 17:50:18 +0200, David Singer <singer@apple.com> wrote:

>
> On Aug 31, 2012, at 1:55 , Simon Pieters <simonp@opera.com> wrote:
>
>>
>> I think the pipe and the dot look like noise or typos and the backslash  
>> escaping is very confusing. Authors are confused already about how  
>> things should be escaped in various languages. Let's not make it worse  
>> if we can avoid it.
>
>
> I don't think anyone is particularly wedded to those characters.  I  
> originally suggested [[ and ]] as the bracketing characters, for example.

My proposal has just LFs, same as the syntax for cues.

> Believe it or not, this was designed looking at the obvious case --  
> inline stylesheets.  We wanted a terminating line that was extremely  
> unlikely in CSS, so the need to escape it, though formally possible,  
> would almost never arise.  Off-hand I can't think that blank lines are  
> ever semantically important in CSS, so it's OK to delete them if you  
> prefer not to escape them, and likewise backslash as a line-start  
> character would be rare.  All this means that though the escaping syntax  
> is 'complete' (we haven't designed it so that we have a problem in  
> future, in that anything *can* be included), it'll rarely be needed for  
> the immediate use-case.  But there are other escape characters that have  
> these characteristics; if taste (or other use cases) suggest other  
> approaches, that's fine by me.

The main reason I'm against escaping is that CSS already has an escaping  
mechanism, and we all know how confusing it gets when having to deal with  
multiple layers of escaping. The proposed escaping is even inconsistent in  
that the backslash escaping is only applied if it's the first character of  
the line rather than all characters, which makes it even more confusing.

> Tucking the style-sheet into the header also makes sense if you see it  
> as 'presentational' rather than semantic.  Just like in days of yore you  
> could present HTML without CSS, the semantic content of VTT should be  
> there even if you don't style it using CSS (and we have enough intrinsic  
> markup to achieve that, IMHO). Existing parsers skip the header; using  
> that they also skip what mostly appear to be invalid cues is more  
> fragile, IMHO.

Existing parsers also skip invalid cues. It's exactly as robust. At least  
assuming they implement the spec. The parser is specified with defined  
error handling precisely so that we can extend it with new syntax at  
different places and can know how existing (conforming) parsers will  
behave.

Are you saying there are parsers that don't implement the spec? If so, why  
is it less likely that they catch fire when seeing a header than when  
seeing an invalid cue? Since the format is not wide-spread yet, surely  
such parsers, if they exist, can be fixed to conform to the spec without  
facing compat problems?

> David Singer
> Multimedia and Software Standards, Apple Inc.
-- 
Simon Pieters
Opera Software

Received on Sunday, 2 September 2012 07:42:48 UTC