RE: TextTrackCue discussions

Is there an assumption that thin or thick TextTrackCues would be for text only representations?  The existing cue definition (not the newer drafts) can adequately source styled cues and works with getCueAsHTML on separate WebVTT or TTML caption files.  For compatibility reasons, these should continue to work.

The use of format specific cue objects like VTTCue may allow tuned attributes for a specific format, but they also fragment the programming model and make it more difficult for websites to support content with mixed caption formats, do they not?

I have had some side discussions with Silvia and others about the overarching goals of this revision.  Some have replied that it is to focus format specific syntax and features on objects that clearly have a format specific intent.  That would seem predicated on an assumption that a format agnostic solution, usually the desired goal for web specifications, is not possible.  Do we agree that is the case?

Jerry

-----Original Message-----
From: Brendan Long [mailto:self@brendanlong.com] 
Sent: Monday, September 9, 2013 9:03 AM
To: Silvia Pfeiffer
Cc: HTML WG (public-html@w3.org)
Subject: 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).

Received on Friday, 13 September 2013 00:33:12 UTC