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

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

--- Comment #14 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
(In reply to comment #12)
> > 
> > In view of this specification, I suggest adding .text back into TextTrackCue
> > as a generic means of accessing the unchanged content of a cue. It might
> > make sense to rename that to .content to be more generic for binary and
> > other types of timed tracks.
> 
> ok, but I'd prefer keeping the name unchanged, since DOMString return value
> is always text as it were

OK. I've changed http://www.w3.org/html/wg/wiki/User:Spfeiffe/TextTrackChange
accordingly.


> > I can see a problem with having getCueAsHTML() on the "base class". It
> > requires application of a conversion algorithm to the original cue content,
> > converting it to HTML. However, the UA only knows which conversion algorithm
> > to apply when being told what type the cue is
> 
> I do not agree that the UA needs to be told what kind of cue it is. In fact,
> the UA has better information than the client JS in this regard.

I can see that being the case for in-band cues, but for cues that are created
by JS? Hardly.

> I agree it
> would be useful to allow the author to provide authorial hints to the UA in
> the <track/> element that can help the UA better determine the type of the
> referenced track resource, but in this case, the authorial hint is akin to
> specifying @type on <img>.

I agree that providing information about the file format to the browser is
useless - if it can interpret it, it will, and if it can't, telling it what it
is doesn't help. However, I was referring to the content type of the cue, not
of the track. If you create a TextTrackCue in JS, you can create it such that
.text contains a WebVTT caption cue, or a TTML caption cue. Only when trying to
render it to HTML will you need to interpret it as WebVTTCue or TTMLCue.


> > For example, assuming that the UA is given a WebVTT file for a <track> of
> > @kind=metadata whose cues consist of image data URLs. A getCueAsHTML()
> > function is pretty useless on such a track, and as a JS developer, I would
> > know that. So I would not want to interpret that track as a WebVTTCue, but
> > instead just use TextTrackCue.text to access the content, and then interpret
> > the content as a dataURL that I hand to <img @src> elements.
> 
> I guess you are suggesting that the "convert to HTML" algorithm is not well
> defined for VTT either. Perhaps WebVTTCue shouldn't provide a getCueAsHTML()
> method either?

That is indeed a good question, but one to be discussed in the CG. I personally
think that we need to distinguish between the encapsulation file type and the
cue file type and that cue file types can have different interpretation
algorithms even for the same encapsulation file type.



> > > It means I can write:
> > > 
> > > if (cue.type == "text/x-my-metadata")
> > >   useTextAccordingToMyMetadataFormat(cue.text);
> > > else if (cue.type == "text/x-your-metdata")
> > >   useTextAccordingToYourMetadataFormat(cue.text);
> > > 
> > > The demux/decoder can or often will determine the text track format, and can
> > > provide this as a hint to client JS.
> > 
> > I thought that's what the in-band metadata track dispatch type
> > (http://www.whatwg.org/specs/web-apps/current-work/#text-track-in-band-
> > metadata-track-dispatch-type) was for (see IDL attribute of TextTrack
> > http://www.whatwg.org/specs/web-apps/current-work/#texttrack ).
> 
> That won't work for two reasons: (1) it is restricted to @kind metadata, and
> (2) it is restricted to in-band.

I think we could change that, while there is no implementation of that
attribute in browsers yet. We would lift both restrictions and could rename it
to @cueType and it would provide a hint as to what algorithm to use to
interpret the cue content of a TextTrack. E.g. "D_WEBVTT/captions" would use
the caption/subtitle rendering algorithm of WebVTT, while "D_WEBVTT/chapters"
would use a different rendering algorithm and "D_WEBVTT/metadata" would not do
any rendering interpretation at all. Other formats would set defined types,
too.



> The main problems are not technical, they are (1) spec uncertainty
> (introducing possible backwards incompatible changes for 5.0 to 5.1), (2)
> publishing schedule, and (3) ipr commitments.

The idea is to introduce the changes here to 5.0, too, if all browsers agree to
implement them.

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

Received on Sunday, 12 May 2013 11:46:44 UTC