This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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.
So what happens when those <track> elements are inserted as children of other <video> elements?
Throw an exception when trying to insert them into any document at all, not just as children of other <video> elements.
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.
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.
We discussed this a bit further and concluded that the spec is fine except onerror and onload should be removed from TextTrack.
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.
That sounds more reasonable (moving the loading mechanic to just the element). I'll investigate if that'd work.
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.
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.
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.
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