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

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

--- Comment #9 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
(In reply to comment #8)
> > 
> > > Very simple: (1) it's there now (on TextTrackCue in 5.0)
> > 
> > There was a lot more on TextTrackCue before, not just these two members. Why
> > are these two members special?
> 
> The other members that have been moved have not been written into external
> specs and used by content authors, at least in the domain I'm dealing with.

The relevant external spec is:
http://www.cablelabs.com/specifications/CL-SP-HTML5-MAP-I02-120510.pdf

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.

I'd also suggest to the authors of that specification to return a more specific
WebVTTCue object or a TTMLCue object or CEA708Cue object which has all the API
of the TextTrack object plus a getCueAsHTML() and an algorithm to convert the
.content to HTML (and any other custom API that these formats would require).
Without the conversion algorithm, getCueAsHTML() is pretty useless anyway.


> > > (2) it's implemented (in a variety of UAs)
> > > (3) it's being used
> > 
> > The model of every format's interface having these members is completely
> > backwards compatible with what is implemented and used, as far as I can
> > tell, without making future interfaces meaningless and confusing.
> 
> It is also reasonable to leave them on the base class and have the base
> class return a nonce result in the absence of an override.

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 of and if it has a conversion algorithm for
that type available. In the general case - in particular for @kind=metadata
tracks - such a conversion algorithm is not available.

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.

We could eventually standardise a specific BinaryWebVTTCue API, inheriting from
TextTrackCue that adds a getCueAsDataURL() or getCueAsArrayBuffer() function
(similar to the FileReader API http://www.w3.org/TR/FileAPI/#dfn-filereader) .
getCueAsHTML() certainly makes no sense in such an Object (though .content
would).


> > > and (4) the proposed
> > > change to remove it doesn't solve any problem but creates new problems.
> > 
> > It solves the problem of the base interface having attributes that don't
> > make sense for every format.
> 
> There is no design principle that requires this.

It's not just about making sense - it's about creating less problems. See my
example above with the image data URIs. If a developer was to use
getCueAsHTML() on the dataURI, the binary data URI was interpreted according to
the WebVTT-to-HTML algorithm, which could have all sorts of consequences. I'd
regard that as a potential security hole.


> > > As presently defined, an author can use knowledge about possible track
> > > sources or content and can use this in combination with what is returned
> > > from text to guess the cue type.
> > 
> > You don't need to guess the cue type. Just look at what interface it
> > implements.
> 
> The presence of a text attribute doesn't tell you anything about the syntax
> or semantics of its values. Only when you know the text track format type
> can this be reliably deduced. In the absence of such information from the
> demux/decoder, only a priori knowledge of the source can be used if that
> info is available. Otherwise one has to guess.
> 
> > 
> > 
> > > It would be better if the UA used knowledge
> > > from its decoders to provide a more concrete hint of the track type. But
> > > even that wouldn't eliminate the widespread utility of having a text
> > > attribute in the base cue class.
> > 
> > I have no idea what this means.
> 
> 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 ).

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

Received on Monday, 6 May 2013 07:33:10 UTC