On Sat, 25 Dec 2010 06:39:02 -0000, Ian Hickson <[email protected]> wrote:
[...]
On Fri, 5 Nov 2010, Bruce Lawson wrote:
http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#sourcing-in-band-timed-tracks
says to create TimedTrack objects etc for in-band tracks which are then
exposed in the API - so captions/subtitles etc that are contained in the
media container file are exposed, as well as those tracks pointed to by
the <track> element.
But
http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#timed-track-api
implies that the array is only of tracks in the track element:
"media . tracks . length
Returns the number of timed tracks associated with the media element
(e.g. from track elements). This is the number of timed tracks in the
media element's list of timed tracks."
I don't understand why you interpret this as implying anything about the
track element. Are you interpreting "e.g." as "i.e."?
Suggestion: amend to say "Returns the number of timed tracks associated
with the media element (e.g. from track elements and any in-band track
files inside the media container file)" or some such.
I'd rather avoid talking about the in-band ones here, in part because I
think it's likely to confuse authors at least as much as help them, and
in
part because the terminology around in-band timed tracks is a little
unclear to me and so I'd rather not talk about them in informative text.
:-)
If you disagree, though, let me know. I can find a way to make it work.
I disagree, but not aggressively vehemently. My confusion was conflating
"track elements" with the three instances of the phrase "timed tracks" in
close proximity.
I suggest that "Returns the number of timed tracks associated with the
media element (i.e. from track elements and any packaged along with the
media in its container file)" would be clearer and avoid use of the
confusing phrase "in-band tracks".
