(In reply to comment #0)
> In Section 4.8.10.12.5 Text track API, appears the following language:
> 
> "The getCueAsHTML() method must convert the text track cue text to a
> DocumentFragment for the media element's Document, using the appropriate rules
> for doing so. For example, for WebVTT, those rules are the WebVTT cue text
> parsing rules and the WebVTT cue text DOM construction rules. [WEBVTT]"
> 
> It would be useful to add clarifying information to the end of this paragraph
> (or in a new paragraph) as follows:
> 
> "Conversion rules for text track cue text other than WebVTT is expected to be
> defined by other specifications. If an HTML user agent does not recognize the
> text track cue format or does not support conversion rules specified for that
> format, then getCueAsHTML() should return a DocumentFragment containing a
> single Text node whose data attribute is identical to the text track cue text."

Alternatively in this new text, and perhaps better, would be:

"... should return null."

which would be a clear indication to script that the UA does not know or support
conversion to HTML.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: no spec change
Rationale: This is already described in this section:

http://www.whatwg.org/specs/web-apps/current-work/#guidelines-for-exposing-cues-in-various-formats-as-text-track-cues

i'd like normative text regarding what should be returned by getCueAsHTML() in the case that the UA does not know the format or does not support conversion of a known format; i would suggest that null be returned in such cases

(In reply to comment #3)
> i'd like normative text regarding what should be returned by getCueAsHTML() in
> the case that the UA does not know the format or does not support conversion of
> a known format; i would suggest that null be returned in such cases

If the UA doesn't know the format at all, why would it expose the track in the first place? It seems that anything that has a text representation can be serialized, and anything else shouldn't be a TextTrackCue at all.

(In reply to comment #4)
> (In reply to comment #3)
> > i'd like normative text regarding what should be returned by getCueAsHTML() in
> > the case that the UA does not know the format or does not support conversion of
> > a known format; i would suggest that null be returned in such cases
> 
> If the UA doesn't know the format at all, why would it expose the track in the
> first place? It seems that anything that has a text representation can be
> serialized, and anything else shouldn't be a TextTrackCue at all.

that's a good point (about not exposing a possible text track if the format is not known or supported); perhaps there should be normative language to that effect?

regarding exposing raw non-text formats, at least one mapping from binary metadata content to a (base64) text representation in a text track cue has been defined at:

http://www.cablelabs.com/specifications/CL-SP-HTML5-MAP-I01-120120.pdf

so it would not do to prohibit exposing binary track data via text track cues; note that a mapping from CEA-608 or CEA-708 closed caption data (also binary) into text track cues is likely to be defined at some point;

> that's a good point (about not exposing a possible text track if the format is
> not known or supported); perhaps there should be normative language to that
> effect?

There is. That's what's I cited for you earlier.

You can't get to the situation you are describing.

(In reply to comment #6)
> > that's a good point (about not exposing a possible text track if the format is
> > not known or supported); perhaps there should be normative language to that
> > effect?
> 
> There is. That's what's I cited for you earlier.
> 
> You can't get to the situation you are describing.

ok, based on one reading of 4.8.10.12.2 (in-band):

"When a media resource contains data that the user agent recognises and supports as being equivalent to a text track, the user agent runs the steps to expose a media-resource-specific text track with the relevant data, as follows."

and of 4.8.10.12.3 (out-of-band):

"If the fetching algorithm fails for any reason ... or if the sniffed type of the resource is not a supported text track format, then queue a task to first change the text track readiness state to failed to load..."

i can agree that no spec change is necessary; however, it would be a little more clear if 4.8.10.12.2 had an "otherwise... do not expose ... a media-resource-specific text track" as the the alternate to "when ..."

That would be like saying "if you are able to float off into the air, then do so. Otherwise, make sure you do not float off into the air". How is a UA supposed to expose something that it doesn't know how to expose? By definition if it exposes it then it knows how to expose it.

withdrawn