Re: TextTrackCue discussions

On 09/08/2013 06:41 PM, Silvia Pfeiffer wrote:
> 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.
I agree. My point is that if we create a new DVDCue class, it should be
required to implement getCueAsHTML().

> [Constructor(double startTime, double endTime, DOMString text)]
> interface GenericCue : TextTrackCue {
>            attribute DOMString text;
>   DocumentFragment getCueAsHTML();
> };
This is basically what I had in mind, although personally I would put
.text in TextTrackCue, since all cues should have it, whether the
browser can parse them or not, right?

> 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();
> };
It would be nice if we could assume all cue formats support this
interface, but from Glenn and Simon's responses, it doesn't sound like
that's realistic. I think there's nothing wrong in principle with using
WebVTT's semantics where other format support it though, since
consistency is extremely useful.

> 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.
Isn't .text used in unparsed cues though? It seems dangerous to return
unparsed cue content in getCueAsHTML(), since that would make it easier
for JS developers to accidentally render unparsed cue content (which
would be particularly annoying with something like CEA708, where the
unparsed content is binary, probably base64 encoded in .text).