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

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

--- Comment #8 from Glenn Adams <glenn@skynav.com> ---
(In reply to comment #7)
> (In reply to comment #5)
> > 
> > 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 don't understand the relevance of this to this bug.

You left out the relevant context from 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.

You noted that the client JS may not "know what kind of cue it is". I'm
reminding you that it was requested to have the UA provide type information to
the client JS, but that was never implemented in the spec.

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

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

> 
> 
> > 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. Does Node.nodeValue make sense
in every Node type? Why not remove it also? Node.nodeName? CustomEvent.detail?

> 
> What problems does it create?

Please read my previous responses. I would just be repeating myself to respond
again.

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

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

Received on Tuesday, 30 April 2013 18:54:06 UTC