Re: TextTrackCue discussions

> but I feel strongly that the primary interface should be useful and standardized

Sounds like a reasonable and logical requirement!

-- Pierre

On Thu, Jul 25, 2013 at 2:21 PM, Glenn Adams <glenn@skynav.com> wrote:
> +1
>
>
> On Tue, Jul 23, 2013 at 10:26 AM, Brendan Long <self@brendanlong.com> wrote:
>>
>> My opinion was that we should distinguish between Cue objects based on
>> semantics (if they are chapters, descriptions, subtitles etc) and not
>> based on the name of the serialisation file format that provides it
>> (WebVTTCue, TTMLCue), because there are many file formats that will
>> provide the same information to the browser.
>>
>>
>> In summary, the proposed change is as follows:
>>
>> * add .text back onto TextTrackCue
>> * add a constructor back onto TextTrackCue
>>
>> [Constructor(double startTime, double endTime, DOMString text)]
>> interface TextTrackCue : EventTarget {
>>            attribute DOMString text;
>>   ...
>> };
>>
>> I agree with this, but I think it needs to go (at least) one step further.
>> To be usable by HTML authors, we need to present standard interfaces.
>> Telling them "you can look at the [some caption format] spec" doesn't help,
>> because a given page may not know what the format of a video is. I don't
>> look up the JPEG spec whenever I want to display an image.
>>
>> I actually think the HTML5 CR version is close to perfect, it just
>> contains a small amount of style information which is specific to WebVTT. If
>> you remove that, you get a good interface for any cue which can be rendered:
>>
>> interface TextTrackCue : EventTarget {
>>   readonly attribute TextTrack? track;
>>
>>            attribute DOMString id;
>>            attribute double startTime;
>>            attribute double endTime;
>>            attribute boolean pauseOnExit;
>>            attribute DOMString text;
>>   DocumentFragment getCueAsHTML();
>>
>>            attribute EventHandler onenter;
>>            attribute EventHandler onexit;
>> };
>>
>> This way, any web author can take any video and look through the cues,
>> without knowing or caring what their original format was.
>>
>> The only thing in this that may not apply to all cues is the html part,
>> but we could allow it to be null for cases where cues aren't meant to be
>> displayed. Any caption that can be displayed should be able to present its
>> content as HTML.
>>
>> If people want a bunch of other attributes, I'd be happy with that in a
>> subclass, but I feel strongly that the primary interface should be useful
>> and standardized (in the HTML spec, saying "it will be standardized
>> somewhere else" is cheating).
>
>

Received on Thursday, 25 July 2013 13:22:42 UTC