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

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

--- Comment #10 from Ian 'Hixie' Hickson <ian@hixie.ch> ---
If you know what kind of cue it is, then you just use its API.

If you don't know what kind of cue it is, then the suggested features here are
pointless.

Note that there is now a way to find out what kind of cue it is, namely, check
what kind of interface the cue object implements.


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

This makes no sense. Just put the attributes into the format-specific API that
you implement, and everything will just work.


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

No, it's not reasonable, it's non-sensical, as I've explained.


> > 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 common sense language design.


> Does Node.nodeValue make sense in every Node type? Why not remove it also? 
> Node.nodeName? CustomEvent.detail?

Those are all great examples of _terrible_ API design.


> > What problems does it create?
> 
> Please read my previous responses. I would just be repeating myself to
> respond again.

You haven't listed any actual problems so far.


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

I'm not suggesting doing that. I'm suggesting looking at what interface the
object implements. WebVTTCue, MyOwnProprietaryCue, TTMLCue, whatever.


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

Why can't you write:

   if (cue instanceof WebVTTCue)
      useTextAccordingToMyMetadataFormat(cue.text);
   else if (cue instanceof YourMetadataCue)
      useTextAccordingToYourMetadataFormat(cue.dataheader, cue.databody);

...or whatever YourMetadataCue exposes?

I don't understand why this would mean we had to expose .text on every format.


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

That spec can trivially be updated by just having it create an MPEG2Cue instead
of a TextTrackCue (or whatever the interface should be). All problems solved,
as far as I can tell. It's backwards-compatible, and fits the new API, and
doesn't result in any meaningless APIs.


> In view of this specification, I suggest adding .text back into TextTrackCue
> as a generic means of accessing the unchanged content of a cue.

That makes no sense at all. The fix here is not breaking HTML, it's fixing the
spec above to actually define its own cue format. The entire point of breaking
out the cue formats is so that this is possible.


> It might make sense to rename that to .content to be more generic for binary 
> and other types of timed tracks.

It doesn't make sense to have an API that is _by definition_ undefined in this
manner.


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

That's what should happen, except without the members on TextTrackCue. They are
of no use if you have a dedicated API.


> 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's about different kinds of cues within a specific format (e.g. a metadata
cue vs a chapter cue in WebVTT). This bug is about different formats (e.g. MPEG
vs WebVTT).

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

Received on Tuesday, 7 May 2013 05:27:52 UTC