Re: TextTrackCue discussions

On Mon, Sep 9, 2013 at 4:30 AM, Brendan Long <self@brendanlong.com> wrote:
>
> But for image formats the browser does understand, you would expect it to
> present a consistent interface for the parts that are consistent (all images
> should have height, width and pixel data).

Right.

>>> I find it hard to believe that there's any cue format
>>> that can't be represented in HTML, and I think to make things reasonable for
>>> JS developers, we should force that format to always be available (although,
>>> for efficiency, an implementation could choose to create it lazily of
>>> course).
>>
>> Binary cue formats don't have a HTML representation, e.g. DVD subtitles.
>
> <img src="data:image/bmp;base64,......" /> would work. It's not as nice as
> getting text, but it's about as good as you can do for image-base subtitles.

That would require converting DVD raster graphics to an img format
that the browser understands. Once a browser implements that, there
are likely other attributes that it will implement, so a specific
DVDCue interface would be created. The abstract TextTrackCue interface
supports creating this and I think we have already agreed that
reverting that to what the WHATWG spec has is the way to go:

interface TextTrackCue : EventTarget {
  readonly attribute TextTrack? track;

           attribute DOMString id;
           attribute double startTime;
           attribute double endTime;
           attribute boolean pauseOnExit;

           attribute EventHandler onenter;
           attribute EventHandler onexit;
};


The question now is: should there be a thin GenericCue interface or a
thick TextCue interface as the parent for text-based cues.

Here's a brain storm on how it could be:


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

OR

enum AutoKeyword { "auto" };
enum DirectionSetting { "" /* horizontal */, "rl", "lr" };
enum AlignSetting { "start", "middle", "end", "left", "right" };
[Constructor(double startTime, double endTime, DOMString text)]
interface TextCue : TextTrackCue {
    attribute DirectionSetting vertical;
    attribute boolean snapToLines;
    attribute (long or AutoKeyword) line;
    attribute long position;
    attribute long size;
    attribute AlignSetting align;
    attribute DOMString text;
  DocumentFragment getCueAsHTML();
};

I'm now thinking .text could be restricted to just plain text. Thus,
I've moved getCueAsHTML() into these interfaces, too, seeing as it
could simply return a DocumentFragment with plain text. There could be
rendering for the appropriate @kind values, which would only be
influenced by the attributes. With GenericCue, it would just be
rendered bottom center by default, with TextCue, we'd also get
positioning and directionality. This would neatly cover simple SRT,
and restricted versions of other caption formats, too.

Then we get to move advanced markup and rendering functionality into
more specific interfaces.

For example, VTTCue will be adapted to one of these:

enum AutoKeyword { "auto" };
enum DirectionSetting { "" /* horizontal */, "rl", "lr" };
enum AlignSetting { "start", "middle", "end", "left", "right" };
[Constructor(double startTime, double endTime, DOMString text)]
interface VTTCue : GenericCue {
    attribute DOMString regionId;
    attribute DirectionSetting vertical;
    attribute boolean snapToLines;
    attribute (long or AutoKeyword) line;
    attribute long position;
    attribute long size;
    attribute AlignSetting align;
};

OR

[Constructor(double startTime, double endTime, DOMString text)]
interface VTTCue : TextCue {
           attribute DOMString regionId;
};

with .text containing VTT specifics and getCueAsHTML() converting VTT
cue markup to HTML.

Thoughts?

Cheers,
Silvia.

Received on Monday, 9 September 2013 00:42:19 UTC