[Bug 23113] Deal with mode for TextTrackCues that are not VTTCues

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

--- Comment #7 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
(In reply to Philip Jägenstedt from comment #1)
> Isn't inBandMetadataTrackDispatchType/cueFormatHint specifically a signal
> for JavaScript rendering, something that the UA will expose but ignore
> itself?

@kind=metadata and @inBandMetadataTrackDispatchType both indicate that there is
no native browser rendering.

We still have to resolve whether @inBandMetadataTrackDispatchType is allowed to
be combined with other @kind values. Eric's suggestion was not to - and I tend
to agree.


> In any case, would it not also solve the problem to allow the spec that
> defines the interface (like VTTCue) also define whether or not setting
> mode='showing' is possible?

That doesn't work: "showing" doesn't mean it's displaying something - it
actually means that the track is active and potentially showing something [1].
So, making a metadata track "showing" just means to make the TextTrackCueList
available.

[1]
http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#dom-texttrack-mode



However, we should probably explain in [1] that even for tracks with
@mode="showing", it's possible that cues are being displayed, but not listed in
the live TextTrackCueList, as explained by Eric [2].

[1]
http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#dom-texttrack-mode
[2] http://lists.w3.org/Archives/Public/public-html/2013Sep/0014.html

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

Received on Monday, 16 September 2013 04:11:09 UTC