This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
+++ This bug was initially created as a clone of Bug #18971 +++ TextTrack does not contain an id attribute like AudioTrack & VideoTrack so they can't be reference by Media Fragment URIs like audio & video can. I propose that the id attribute be added to TextTrack and a getTrackById() method be added to TextTrackList so that these objects are consistent with the audio and video counterparts.
(In reply to comment #0) > +++ This bug was initially created as a clone of Bug #18971 +++ > > TextTrack does not contain an id attribute like AudioTrack & VideoTrack so > they can't be reference by Media Fragment URIs like audio & video can. > > I propose that the id attribute be added to TextTrack and a getTrackById() > method be added to TextTrackList so that these objects are consistent with > the audio and video counterparts. +1
What's the use case? :-)
(In reply to comment #2) > What's the use case? :-) The same use cases that justify the existance of AudioTrack.id & VideoTrack.id. :) This is primarily a call for consistency across all XXXTrack types. Inband text tracks would likely have IDs similar to the audio and video tracks and applications may want to select these tracks by ID though Media Fragment URIs or JS.
I think this was discussed during TPAC in Lyon last year and was agreed.
<track> (HTMLTrackElement) has an id as part of the global attributes. TextTrack could reuse that for tracks being created through <track>.
So a readonly attribute?
(In reply to comment #6) > So a readonly attribute? Yes, I think that makes sense. Should probably be added to addTextTrack then, so it can be set for JS-created tracks.
Adding a TextTrack.id wouldn't let you select them via media fragment URLs. It would let you track down which text track you want from JS, though, for in-band tracks. So I've added it. I don't see the use case for an argument to addTextTrack().
Checked in as WHATWG revision r7947. Check-in comment: Add TextTrack.id and TextTrackList.getTrackById to enable in-band text tracks to be identified and selected from JS http://html5.org/tools/web-apps-tracker?from=7946&to=7947
This is just a FYI: the original WD of the media fragment URI spec had the track references included, see http://www.w3.org/TR/2011/CR-media-frags-20111201/#naming-track . I believe they were removed when going onto the REC track, because REC can only include features that have been implemented interoperably. So, if implemented, it would indeed be possible to reference tracks by their track id. The use case for adding an id parameter to addTextTrack is to allow JS developers to author track identifiers. Since the id attribute is read-only, we're now excluding JS developers from authoring tracks with an explicit identifier and referencing their tracks by id. I'm not overly worried by this restriction, since JS devs can always hold onto a reference to their newly created text tracks. It's just a small inconsistency.