Re: TextTrackCue discussions

On 09/20/2013 11:44 AM, Glenn Adams wrote:
>
> On Fri, Sep 20, 2013 at 5:13 AM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com <mailto:silviapfeiffer1@gmail.com>> wrote:
>
>     On Fri, Sep 20, 2013 at 5:49 PM, Philip Jägenstedt
>     <philipj@opera.com <mailto:philipj@opera.com>> wrote:
>     > What would the text property contain when the browser doesn't
>     know the
>     > encoding?
>
>     Return an empty string. That can also be used by the JS dev to know
>     that they need to look at the .data ArrayBuffer.
>
>
> No. It should return null. As Simon points out, an empty string is a
> legitimate value for a cue.
I agree with this. Returning an empty string is ambiguous, and null is
explicit.

> However, I would suggest not to inherit TTMLCue from RawCue, since as
> Simon pointed out earlier, you'd like JS devs to be able to do
>
>    var raw_cue = cue instanceof RawCue;
>
> to detect that a cue is not taken care of by the UA. If TTMLCue
> inherits from it, that doesn't work.
I'd argue that JS developers should check for behaviour instead of
types. If you want to know if a cue has an HTML representation, you
should check if getCueAsHTML() exists. Since .data should exist in every
cue type, it would be good if it was included in an interface as high-up
as possible. Adding it to RawCue may be dangerous though, since if we
wanted to change RawCue, it would automatically change TTMLCue, which
could lead to situations that we don't want. I find it hard to imagine a
situation where a RawCue would have any information that a TTMLCue
wouldn't though..