14241 2011-09-22 11:45:04 +0000 <track> Move readyState, onerror, and onload from TextTrack to HTMLTrackElement 2011-10-15 00:11:46 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#texttrack P3 blocker --- 14294 1 contributor ian annevk eoconnor eric.carlson ian mike philipj public-html-admin public-html-wg-issue-tracking silviapfeiffer1 zcorpan public-html-bugzilla oldest_to_newest 57148 0 contributor 2011-09-22 11:45:04 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/the-iframe-element.html Multipage: http://www.whatwg.org/C#texttrack Complete: http://www.whatwg.org/c#texttrack Comment: <track> Merge HTMLTrackElement and TextTrack into one interface Posted from: 2001:4c28:a030:30:223:32ff:fec2:96fa by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.21 Safari/535.2 57150 1 zcorpan 2011-09-22 11:58:24 +0000 I think the API could be better if the TextTrack stuff were moved to the HTMLTrackElement interface and <track> elements are used instead of TextTrack objects. It's dodgy to have both an element and an object, especially with events and event handlers: The spec says to fire 'load' and 'error' on <track> but TextTrack has onload and onerror handlers (nowhere does the spec say to fire 'load' or 'error' on TextTrack AFAICT). The spec says to fire 'cuechange' on both TextTrack and <track>. (First I considered whether the spec should make <track onload> reflect TextTrack.onload (like <body onload> reflects window.onload), and only fire the events on the TextTrack object, but then I wondered why there are two objects to begin with.) We don't have an element and an object for audio, video, images, etc. We just use the element. Should do the same with <track>. For in-band tracks, you would create <track> elements and associate them with the <video> without inserting them to the document. 57362 2 ian 2011-09-26 19:42:46 +0000 So what happens when those <track> elements are inserted as children of other <video> elements? 57397 3 philipj 2011-09-27 08:02:02 +0000 Throw an exception when trying to insert them into any document at all, not just as children of other <video> elements. 57504 4 annevk 2011-09-29 12:13:20 +0000 I do not think it is a good idea to introduce such an odd exception to the DOM platform. Maybe just as with StyleSheet the events should only only be dispatched on nodes in the document that caused creation of the StyleSheet. 57505 5 philipj 2011-09-29 12:51:10 +0000 In other words, no error/load event is fired at the TextTrack object, ever? That would certainly be an improvement. In any case, it couldn't ever fire for anything but a TextTrack associated with a <track> element, as that's the only thing that loads and parser external resources. 57550 6 zcorpan 2011-09-30 09:14:59 +0000 We discussed this a bit further and concluded that the spec is fine except onerror and onload should be removed from TextTrack. 57564 7 philipj 2011-09-30 14:56:34 +0000 Shouldn't we move readyState to HTMLTrackElement as well in that case? It doesn't make any sense for script-created tracks and for in-band tracks LOADED seems like a bad idea for the same reason that <video> doesn't have a load event. 57566 8 ian 2011-09-30 16:15:09 +0000 That sounds more reasonable (moving the loading mechanic to just the element). I'll investigate if that'd work. 57745 9 ian 2011-10-04 01:04:59 +0000 Yeah, that should work. The text track readiness state wouldn't change, it just wouldn't be exposed for in-band tracks (or MutableTextTracks, until I drop them). readState on HTMLTrackElement would just expose the readiness state on its text track. As far as I can tell, TextTrack.onload and .onerror aren't used today anyway. 57766 10 philipj 2011-10-04 08:19:31 +0000 Sounds good. I filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=14378 which is entangled with the loading machinery in case you want to do both at the same time. 58264 11 ian 2011-10-15 00:11:02 +0000 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: see diff given below Rationale: Did comment 9. It was an easy edit so I didn't do bug 14378 at the same time. 58265 12 contributor 2011-10-15 00:11:46 +0000 Checked in as WHATWG revision r6689. Check-in comment: Move TextTrack.readyState to HTMLTrackElement. http://html5.org/tools/web-apps-tracker?from=6688&to=6689