Re: TextTrackCue discussions

On Sat, Sep 7, 2013 at 5:20 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> On Sun, Sep 8, 2013 at 3:56 AM, Glenn Adams <glenn@skynav.com> wrote:
> >
> > On Sat, Sep 7, 2013 at 2:11 AM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com>
> > wrote:
> >
> >> >> > TTMLCue will have at least:
> >> >> >
> >> >> > interface TTMLCue {
> >> >> >   DocumentFragment getCueAsTTML(); // obtain TTML intermediate
> >> >> > synchronic
> >> >> > document (ISD)
> >> >>
> >> >>
> >> >> I would expect that to end up in .text - makes more sense to me.
> >> >
> >> >
> >> > That would be a waste of effort, i.e., to serialize XML into text only
> >> > to
> >> > expose it to JS which would have to deserialize it from text as XML
> >>
> >> I follow you up to here - after this, JS would interpret the XML and
> >> render it.
> >>
> >> > to
> >> > modify then mutate deserialize by setting text attribute than have
> >> > implementation deserialize once more into XML.
> >>
> >> I don't know why you would need to do all this.
> >
> >
> > TTMLCue will have already parsed the XML into a Document Fragment. The JS
> > client will manipulate this fragment. It would be very inefficient to
> force
> > the client to manipulate as a serialized text representation.
>
> So what you're saying is that TTMLCue will not allow JS developers to
> change the TTML cue content and get the browser in-built parser &
> renderer to render the changed content for them. I.e. it also won't be
> possible for JS developers to author TTML cues by in script?
>

You appear to be assuming that one needs a text attribute to mutate a cue.
As you probably know, a DocumentFragment may be mutated. The latter will be
much more effective in the case of TTML.


>
> > However, that isn't to say that an UnparsedTTMLCue parent interface
> couldn't
> > expose as text, or, in case UA doesn't parse, then expose only as
> > UnparsedTTMLCue instances.
> >
> > If HTML spec doesn't define an {Unparsed,Generic}Cue interface, then
> we'll
> > define a TTML specific version of this in TTML2.
>
> It would be better to have .text represent the same in TTMLCue as well
> as GenericCue for TTML.
>

See my other email [1] where I suggested a particular API. The only
difference is that I defined text to be non-mutable in UnparsedTTMLCue.

[1] http://lists.w3.org/Archives/Public/public-html/2013Sep/0046.html


>
>
> > Conclusion: if TTML isn't parsed, then it should be exposed in text
> > (serialized XML) form, either by some generic|unparsed cue object or a
> TTML
> > specific unparsed cue object. It should not be exposed from a VTTCue as
> > WebVTT metadata text.
>
> If VTTCue is renamed to TextCue and part of the HTML spec (and thus
> could be made the parent of TTMLCue)


This is a non-starter for me. I will have to strongly object to
reintegrating VTTCue into TextTrackCue.


> , would you still oppose exposing
> TTML content in browsers that don't implement TTMLCue as
> @kind=metadata in .text in TextCue?
>

Yes. For reasons stated previously. In such a case, those browsers should
expose TTML via either an UnparsedTTMLCue (see [1]), or a generic
UnparsedCue (or GenericCue) if this latter is standardized in the HTML
spec. They must not expose as VTTCue metadata, which is broken for many
reasons.


>
> Silvia.
>