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

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

--- Comment #13 from Glenn Adams <glenn@skynav.com> ---
(In reply to comment #10)
> If you know what kind of cue it is, then you just use its API.

If it has one (an API). There should not be a requirement to define a new API
in order to use a different text track media type.

One isn't required to use a different API to interact with different image
types via HTMLImageElement, one isn't required to use a different API to
interact with different A/V media types via HTMLMediaElement.

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

No they aren't. They are no more pointless than defining an HTMLMediaElement
API that can be used with all A/V media types.

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

Again, to repeat myself, this imposes a new, unique requirement on making use
of text tracks that don't hold for images, A/V media, and other interfaces.

What happened to the well-known software concept of generalizing features?

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

I've mentioned that technical definitions are not the only issue here:
publishing schedule and IPR commitments are also at issue.

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

We disagree on what is reasonable. At least I'm not calling your ideas
nonsense. Calling my position nonsense is not a way to have an objective
dialogue.

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

And so is abstracting base classes.

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

They work.

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

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.

These are more important issues than technical perfection with respect to API
design.

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

I understand. And I also understand this requires defining many new interfaces
when generic interfaces can get most of the job done. See HTMLMediaElement.

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

Sure, that would work technically. But it is more brittle, since it will result
in a JS exception when attempting to dereference YourMetadataCue on a UA that
doesn't support "text/x-your-metadata".

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

I didn't say we "have to". I'm saying its convenient and it works. You are
proposing a different approach simply because in your opinion it makes for a
more pleasing API design. Pleasing API design has never been a factor of W3C
APIs. Why should TextTrackCue suffer from an over-zealous desire for some API
design ideal that doesn't exist in practice?

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

Yes, and it may at some point in the future take such an option, but why should
your suggested change force this change in an external spec simply for some
vague notion of API ideology?

> 
> 
> > 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's also called throwing out the baby with the bath water. If having a generic
text attribute works in many if not all cases, then its existence is justified.

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

It is not "undefined" it is just not fully specified for all possible uses.

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

It is not necessary to require a dedicated text track type specific API. That
is my fundamental disagreement with your proposed approach.

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

Correct.

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

Received on Wednesday, 8 May 2013 00:32:04 UTC