[Bug 21851] revert removal of text and getCueAsHTML members; address constructor changes

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21851

--- Comment #20 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
(In reply to comment #19)
> (In reply to comment #11)
> > 
> > It is possible to have an implementation in a UA that parses timed tracks
> > and exposes cues, but the UA has no implementation for how to further parse
> > the cue content.
> 
> This has nothing to do with parsing the cue content. It's about parsing the
> cues.

Actually, this bug is about parsing cue content and not about file formats. The
bug is about getCueAsHTML(), which parses a cue's content given int .text to
HTML.


> In an implementation such as you describe, you'd still have a new Cue
> interface, for whatever text track format you're dealing with.

We've decoupled the format of the cue from the format of the text track file by
having <track> parse any format that a browser cares to support into a list of
Cues. That's our starting point. From there on, we only care about parsing cue
content.


> > It would, of course, be better to have a dedicated API for TTMLCue or
> > SCC708Cue, but if there is no further data than just the cue content,
> > TextTrackCue is entirely sufficient if it has a .content (or .text) API.
> 
> That's really poor API design.
> 
> If you have a potential hierarchy of interfaces, and some leafs of this
> hierarchy would only have one or two APIs, you don't therefore not bother to
> create the leaves and instead put the APIs on the abstract common ancestor.
> You only put things on the abstract common ancestor if they apply to _every_
> descendant interface.

This is assuming that we will have text track formats that provide cues that
don't have text in them. Is this realistic? For example, if I want to provide
timed thumbnails to the browser (for example to do something like the thumbnail
seek in YouTube), I'd continue to use WebVTT and provide data-urls for the
images in the cues. Are you expecting this to be replaced in the future with a
binary file format that delivers images? And would the <track> element still be
the right delivery format for such a binary file format?


> There's no harm in having a "TTMLCue" interface that has a .text API. Or
> alternatively, in having an interface that inherits from the abstract
> TextTrackCue and that is inherited by WebVTTCue, which can then be used for
> those formats where the UA essentially just has a subset of WebVTT (though
> that would be inferior to having separate leaf interfaces, since you'd want
> each one to have its own rendering rules, and it'd be confusing to have a
> single interface used for multiple different rendering rules).

What we need is a means of creating a cue in JS without requiring to
pre-specify what format the cue is in. In this way, JS developers can create
text tracks with cues that contain JSON or plain text, or image URLs or
whatever else they need and then interpret that content as the cues become
active.

I've had a brief discussion with the text track devs in the browsers about
this. They follow your argument that it shouldn't be on the abstract common
ancestor, but suggested we introduce:

[Constructor(double startTime, double endTime, DOMString text)]
interface UnparsedCue : TextTrackCue {
};

Possibly with the .text attribute in it rather than on the base class.

Also, it was argued that since we are making non-backwards compatible changes,
removing the TextTrackCue constructor makes old uses more obviously broken and
it's easier to debug (by just checking the error console).

A further advantage of UnparsedCue is that browsers can parse text track
formats that they understand how to parse (e.g. TTML, MP4 file text tracks),
but for which they don't understand how to parse the individual cues (e.g. SSML
cues in a WebVTT file; or metadata/chapter/description cues in a WebVTT) and
can still make the cues available in JS through UnparsedCue.

Alternatively, we could also rename the abstract ancestor to
AbstractTextTrackCue and make the generic, unparsed cue the TextTrackCue, which
would make it more backwards compatible with what is currently implemented.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 5 June 2013 03:44:10 UTC