Re: TextTrackCue discussions

On Wed, Jul 24, 2013 at 12:13 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
> Yes, the focus of the API is both a full TTML DOM and a mapping to the Cue list from HTML. TTML is indeed similar to SVG or MathML, and
> might conceivably one day be embedded in HTML in the same way. However even absent that, authoring and transcribing tools will be more
> interested in the former, while play-out engines may be more interested in the latter. I also put in a bridge between them, so that for example it is
> possible to create the TTML file from a list of live cues.  TTML markup is of course a lot richer than just time-aligned cue sequences; although
> such can be generated from a TTML file.

Right, that makes more sense now. Could you separate the two APIs into
two different documents? I'm asking because one of them is relevant to
browser vendors for the <track> element and the other is relevant for
other applications which don't care about the <track> API. So, it
would be good to keep them separate.


> I don't really see the TTML Dom part having an analogue in WebVTT, so I'm not especially concerned with consistency there; I'd like it to look and
> feel more like the HTML/SVG/MathML types of DOM so I modelled the main TTML DOM after
> http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html which has types for all the elements. I haven't put in all the attributes in the
> TTML version yet, which is why it perhaps looks a little odd as is

Indeed, the WebVTT is not trying to create WebVTT DOM. I hope there is
no expectation that it will and that the basis for a conversion
between WebVTT and TTML is such a DOM.


> For the Cue centric part, I guess it's a case of whether you prefer typed or untyped hierarchies. If the style-du-jour is untyped, then I'm fine with an
> enum of element names. On reading it's mostly just the difference between using typeof operator or matching an attribute against an enum. While
> I definitely foresee people building TTML files ab-initio in browser based applications; I guess they are less likely to build lists of cue objects
> (depending on how we solve the problem of live captions). I could definitely see reducing the cue representation types down to a single type with
> an enum, but I did it the other way for consistency.

I don't follow. Are you saying that for <track> API TTML cannot follow
the text track model as defined in the HTML spec
(http://www.w3.org/html/wg/drafts/html/CR/single-page.html#text-track-model)
with cues and cue lists?


Thanks,
Silvia.

Received on Wednesday, 24 July 2013 03:09:45 UTC