Re: TextTrackCue discussions

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 codifies what browsers seem to be doing
with unknown cue formats right now. WebVTT just becomes another one of
the formats that get converted to a TextCue. The rendering algorithm
would be based solely on the attributes of TextCue.

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 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.

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

Silvia.

Received on Sunday, 8 September 2013 02:32:07 UTC