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

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

--- Comment #6 from Glenn Adams <glenn@skynav.com> ---
(In reply to comment #5)
> (In reply to comment #4)
> > If you don't know what kind of cue it is, and the cue might return either
> > WebVTT cue text (marked up), base64 data, some random other format, or
> > kittens know what else, then honestly the feature is pointless.
> 
> In some cases, the page's author knows the text track content type, because
> the author chooses what sources to use, and may (but need not) know the text
> track.
> 
> Frankly, I am not satisfied with this state of affairs; however, you and
> others argued against providing UA hints to the client JS in the case this
> isn't true when [1] was closed without really solving the problem.
> 
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=13359
> 
> > I really
> > don't see any value in exposing that, especially given that there's no
> > guarantee anything can be exposed at all. It just doesn't make any sense.
> > What's the use case? If it's just debugging, then just expose the whole
> > object and all its attributes, like console.log does for anything else.
> > 
> > The term "TextTrack" is merely meant to distinguish it from AudioTracks or
> > VideoTracks. There's nothing about TextTracks that forces them to be text;
> > they could equally be named "TimedTracks" (indeed at one point they were, we
> > changed it for unrelated reasons).
> > 
> > It makes no sense to force every cue format interface to find a string
> > representation. There's no use case for it, there's no need for it (every
> > format can offer its own API), there's no benefit to it. All it does is
> > constrain future format developers.
> > 
> > It is no more true that all timed text track formats can expose a string for
> > their cues than it is true that all timed text track formats can expose an X
> > coordinate or a Y coordinate for their cues.
> > 
> > I really do not understand why you want this.
> 
> Very simple: (1) it's there now (on TextTrackCue in 5.0), (2) it's
> implemented (in a variety of UAs), (3) it's being used, and (4) the proposed
> change to remove it doesn't solve any problem but creates new problems.
> 
> 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. 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 guess I should also note that removing from 5.1 creates uncertainty about the
status of these features in 5.0. Will they be removed from 5.0 before it goes
to REC? If so, then when will 5.1 become a REC? All of this produces delay in
testing, patent protection, device certification, and ultimately deployment.

In exchange for this uncertainty, you are saying that there are *some* cases
where the value of a text attribute doesn't make sense. The trade doesn't seem
to be worth it.

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

Received on Tuesday, 30 April 2013 06:41:40 UTC