Re: Streaming of WebVTT

On Fri, Jul 27, 2012 at 4:30 AM, Cyril Concolato <
cyril.concolato@telecom-paristech.fr> wrote:

>  It's a bit unusual for a standard to specify the parsing algorithm, but I
> can understand why.
>

It's not unusual for modern specs.  It's a much more dependable way of
getting to consistent behavior than only specifying a format.

 However, I'm not sure it's a good practice to make future version of the
> files be syntactically invalid with respect to a previous version of the
> standard. The syntax should be aligned with the parsing algorithm. If you
> plan extension points, fine, but add them to the syntax. In this particular
> case, what does this cost you to add it? The risk is only to make the spec
> clearer.
>

It costs time to design a feature properly.  It can hurt adoption to add
features too early, before implementations can catch up with the more basic
parts of the spec.  Also, designing things too early means designing with
less real-world implementation and user experience with those basic parts.

In my first email, I was suggesting a possible way (allowing cue settings
> as CSS properties and using top-level spans) but this might be problematic,
> I don't know. I don't care about the solution, but I think the requirement
> is valid.
>

Can you describe the use case more clearly?  It sounds like you're talking
about trying to interleave WebVTT across a file, like audio interleaving,
which doesn't seem very useful for data as small as captions.  For live
streams (where you don't have the captions in advance), you can make a
separate request for the caption data, possibly specifying the start time
in the request so the user doesn't receive old captions that he won't see.
You can try to interleave captions, but I'm not sure that's been much of a
consideration in WebVTT's design.

-- 
Glenn Maynard