22015 2013-05-13 07:12:09 +0000 TextTrack should have an id attribute 2013-06-09 11:17:57 +0000 1 1 1 Unclassified WHATWG HTML unspecified PC Linux RESOLVED FIXED P2 normal Unsorted 18971 1 silviapfeiffer1 ian acolwell acolwell cyril.concolato eoconnor glenn ian mike philipj public-html-admin public-html-wg-issue-tracking robin zcorpan contributor oldest_to_newest 87585 0 silviapfeiffer1 2013-05-13 07:12:09 +0000 +++ 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. 87607 1 glenn 2013-05-13 15:11:25 +0000 (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 87609 2 zcorpan 2013-05-13 15:30:50 +0000 What's the use case? :-) 87610 3 acolwell 2013-05-13 16:02:46 +0000 (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. 87611 4 cyril.concolato 2013-05-13 16:07:00 +0000 I think this was discussed during TPAC in Lyon last year and was agreed. 87631 5 silviapfeiffer1 2013-05-14 06:41:04 +0000 <track> (HTMLTrackElement) has an id as part of the global attributes. TextTrack could reuse that for tracks being created through <track>. 87632 6 zcorpan 2013-05-14 06:50:12 +0000 So a readonly attribute? 87633 7 silviapfeiffer1 2013-05-14 07:10:49 +0000 (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. 88956 8 ian 2013-06-08 00:04:40 +0000 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(). 88957 9 contributor 2013-06-08 00:05:22 +0000 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 88980 10 silviapfeiffer1 2013-06-09 11:17:57 +0000 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.