Re: A new proposal for how to deal with text track cues

I think I see the basic issue.  WebVTTCue isn't the output of the cue
parser, it's the output of the WebVTT parser.  None of the fields of
WebVTTCue are inherently specific to kind=subtitles (or caption); they're
simply the output of the file-level WebVTT parser.  Not all of them are
used by every renderer, but they're all valid, and they're all parsed in
the same way regardless of @kind.

The cue parser ("WebVTT cue text parsing rules") is run only if you call
getCueAsHTML (or if the cue is actually rendered, of course), and the
output of that is a DocumentFragment.  If you want to add, for example, a
TTML parser for kind=chapters, then the only addition to WebVTTCue would be
a getCueAsTTML() method, which would invoke the TTML parser and return an
interface specific to that format, just like getCueAsHTML() does for
captions.



On Fri, Jun 14, 2013 at 3:57 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> I was told that TTML indeed supports chapters, though I haven't seen
> any TTML files in use for that purpose. They would also just be timed
> cues with plain text, I was told.
>

By the way, while I don't know a lot about TTML, using it for chapters
smells like a really bad idea.  The spec is several times the size of
WebVTT, it's based on XML--that always makes me nervous--and generally
looks heavy and overdesigned.  Hopefully WebVTT doesn't need to depend on a
big and unproven spec, if they're really just timed cues with plain text.
(I can't find chapters in the spec--the word "chapter" appears only once,
in an example.)


On Thu, Jun 13, 2013 at 11:34 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com
> wrote:

>  >> Once a WebVTT file is parsed into a list of cues, the browser should
> >> not have to care any more that the list of cues came from a WebVTT
> >> file or anywhere else. It's a list of cues with a certain type of
> >> content that has a parsing and a rendering algorithm attached.
> >
> > If it has a rendering algorithm attached, then the browser does care
> that it
> > came from a WebVTT file, since that's what that flag indicates.
>
> The object is called WebVTTCue - thus the browser cares that it came
> from a WebVTT encapsulation.
>

Changing that to "TextTrackData" with an attached rendering algorithm of
"WebVTT" is only a more complicated way of saying the same thing--it still
cares that it's WebVTT.

 >  I'm also
> > confused that you're saying you want to split the interfaces for metadata
> > and cues, but that if the platform supports a DVD bitmap caption
> interface
> > in the future, you'd want those to use the same interface, even though
> their
> > data and attributes would be completely different.
>
> Right now, we have one catch-all type cue: cues of kind metadata.
> Other cues have explicit parsing and rendering algorithms associated.
>
> Think about it like that: we understand captions/subtitle cues, have
> defined an explicit parsing and rendering algorithm. We are about to
> do the same for chapter cues - and after that we will do the same for
> description cues. These are similar to the <img>, <video>, <audio>
> tags that we have defined to pull in embedded content. That leaves
> metadata cues for which we don't define a parsing or rendering
> algorithm - just like <embed>/<object> remains as a generic means to
> pull other types of embedded content into the browser.
>

(This response isn't related to what I said, so I'll restate.)

If you think WebVTT subtitles should have a separate interface from WebVTT
metadata, then it's confusing that you would want to use the same interface
for DVD subtitles and WebVTT subtitles, since the latter two are much more
different than the former two.  You said that you want browsers to have a
list of source-independent cues with a rendering algorithm attached, which
means you'd have a SubtitleCue with all of the attributes from both WebVTT
and DVD, and a "algorithm=dvd" flag.  That sounds wrong to me.

-- 
Glenn Maynard