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

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

--- Comment #5 from Glenn Adams <glenn@skynav.com> ---
(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.

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

Received on Tuesday, 30 April 2013 06:23:49 UTC