Re: TextTrackCue discussions

On Fri, Sep 13, 2013 at 2:32 AM, Jerry Smith (WINDOWS) <
jdsmith@microsoft.com> wrote:

> 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?
>

IMO, a single format agnostic cue interface is impractical, and, if imposed
from without, will result in necessary loss of essential format specific
semantics. However, the TTWG hasn't specifically considered this point, so
it would be useful to pose the question there to determine if my opinion is
shared.


> 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).
>
>