Re: TextTrackCue discussions

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

> On Sun, Sep 8, 2013 at 11:07 AM, Glenn Adams <glenn@skynav.com> wrote:
> >
> >
> > 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.
>
> Sure - what interface you give TTMLCue is not what I'm considering here.
> I'm only concerned about alternatives to GenericCue.
>
>
> > [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.
>
> Please read my email carefully. I have not suggested anything like this.
>
> The proposal is to continue having TextTrackCue as the abstract
> interface, then TextCue as an inherited interface, but with all of the
> interface from VTTCue.


That doesn't make any sense. You are again suggesting add VTT semantics to
generic text cues.


> That codifies what browsers seem to be doing
> with unknown cue formats right now.


That's not because its the right thing to do or because it should be
maintained. They implemented it that way because they were working with
interface definitions (i.e., TextTrackCue in HTML5 CR1) that failed to
recognize the existence of non-VTT text tracks. In other words, they
applied the principle "If all you have is a hammer, everything looks like a
nail."



> WebVTT just becomes another one of
> the formats that get converted to a TextCue.


But since TextCue is WebVTT semantics, that is a no-op.


> The rendering algorithm
> would be based solely on the attributes of TextCue.
>

That won't work. The attributes of TextCue as based on VTTCue are not
sufficient and don't align with the attributes or semantics of other
formats.


> I'm not sure if it will work, in particular because I'm not sure about
> the markup in .text and how to render this.


It won't work.


> It seems right now mapping
> cue markup to VTT cue markup is what browsers do, then convert that to
> HTML. That might be sensible because VTT cues have a sensible
> limitation of tags usable in cue markup.
>

No, its because that was the path of least resistance when working with an
existing VTT based track framework.

It would not be a productive use of time to entertain a discussion of which
cue markup is most sensible. The semantics of VTT may make sense for VTT,
but they don't necessarily make sense for other formats, and I'm certain
that any attempt to map TTML, for example, into VTT, will end up throwing
away information and styling semantics.



>
> I'm just trying to find a solution that satisfies all user needs and
> will be implemented by browsers.
>

Then I suggest we stop talking and you do the following:

(1) change HTML 5.1 nightly's definition of TextTrackCue to align with
WHATWG flavor of the day, i.e., remove the constructor and text attribute;
this solves the spec fork problem for this interface;

(2) define in HTML 5.1 nightly a new interface:

[Constructor(double startTime, double endTime, DOMString text))]
interface UnparsedCue : TextTrackCue {
  attribute DOMString text;
}

if you don't like the name UnparsedCue, then change it to something else;

(3) if you wish, change VTTCue to inherit from UnparsedCue into order to
inherit its text attribute; otherwise, define a text attribute directly on
VTTCue;

If you do these changes, then I think we can stop going round in circles,
and instead promote that UA implementers adopt these changes.