Re: WebVTT spec

Hi Ian,

On Sat, Feb 23, 2013 at 5:48 AM, Ian Hickson <ian@hixie.ch> wrote:

>
> Hey guys,
>
> Since my vision of WebVTT doesn't seem well-aligned with the vision of the
> people implementing WebVTT, I'm probably not the best person to continue
> editing the WebVTT spec. Is there anyone who would like to take over?
>

Sorry to hear this - you've done tremendous work in creating WebVTT.

I can offer to take over, though I hope your scrutiny on new features is
not lost with this move and you continue to contribute.


If we do this, I would propose that we move the TextTrackCue interface
> into the WebVTT spec also, since they are very closely linked and it
> would be easier for one person to edit both together rather than try to
> coordinate between specs.
>

I was actually wondering about the split and was considering the opposite,
namely to pull more back into HTML. The TextTrack API and TextTrackCue etc
should continue to stay in HTML, because you can create text tracks and
cues without WebVTT. The parsing rules of cues that the HTML spec accepts,
the DOM construction, the rendering, and the CSS extensions should likely
all go back into HTML for this reason and be formulated independently of
WebVTT.

The WebVTT spec can then become just the specification of a file format
that feeds into the HTML TextTrack API with lots of references to the HTML
spec for browsers. It can then specify the file format in a more general
way, independent of browsers, and describe the expected rendering in more
general words rather than HTML-specific.

That would also allow adding features to the WebVTT spec that browsers can
safely ignore (such as the language and kind metadata headers).

This still mean that we have to synchronize over richer features such as
TextTrackRegion and live captioning for WebRTC.

If we wanted to decouple development here, too, we could probably create a
TextTrack Specification in the HTML WG and move all <track>/TextTrack
related spec text there. It would be possible to do this for TextTrackCue
alone, too, but a more logical splitpoint is the complete TextTrack API.

I'd be happy with either approach (moving it back to HTML or into an
independent spec).

Cheers,
Silvia.