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

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

--- Comment #12 from Glenn Adams <glenn@skynav.com> ---
(In reply to comment #9)
> (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.

ok, but I'd prefer keeping the name unchanged, since DOMString return value is
always text as it were

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

ok, i can agree to not requiring getCueAsHTML() on the base class, but to
define it as a partial interface on subclasses

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

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

As for determining the concrete track resource type, the UA always sees the
bytes before the client JS (except in the case of using MSE to feed those bytes
to the UA). As a consequence, the UA is in a better position to determine the
concrete type of the delivered track bytes.

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

Obviously, if the UA does not already know about a given track format, then it
isn't going to be able to determine either a specific track media type or a
subclass of TextTrackCue that could convert the text track content.

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

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

All you've done here is demonstrate that getCueAsHTML() is not well defined on
VTT  itself. But that is an entirely different problem. If it's a security
hole, then it is a security hole on VTT and its conversion to HTML semantics.

But since I have conceded to not requiring getCueAsHTML() you can address this
as a different bug on VTT at your pleasure.

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

That won't work for two reasons: (1) it is restricted to @kind metadata, and
(2) it is restricted to in-band.

In my estimation, the @kind attribute is completely orthogonal to media type,
and is intrinsically tied to the interpretation and semantics of specific media
types (like VTT).

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

Received on Wednesday, 8 May 2013 00:12:51 UTC