This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 14241 - <track> Move readyState, onerror, and onload from TextTrack to HTMLTrackElement
Summary: <track> Move readyState, onerror, and onload from TextTrack to HTMLTrackElement
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 blocker
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Depends on:
Blocks: 14294
  Show dependency treegraph
Reported: 2011-09-22 11:45 UTC by contributor
Modified: 2011-10-15 00:11 UTC (History)
10 users (show)

See Also:


Description contributor 2011-09-22 11:45:04 UTC

<track> Merge HTMLTrackElement and TextTrack into one interface

Posted from: 2001:4c28:a030:30:223:32ff:fec2:96fa by
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
Comment 1 Simon Pieters 2011-09-22 11:58:24 UTC
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.
Comment 2 Ian 'Hixie' Hickson 2011-09-26 19:42:46 UTC
So what happens when those <track> elements are inserted as children of other <video> elements?
Comment 3 Philip Jägenstedt 2011-09-27 08:02:02 UTC
Throw an exception when trying to insert them into any document at all, not just as children of other <video> elements.
Comment 4 Anne 2011-09-29 12:13:20 UTC
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.
Comment 5 Philip Jägenstedt 2011-09-29 12:51:10 UTC
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.
Comment 6 Simon Pieters 2011-09-30 09:14:59 UTC
We discussed this a bit further and concluded that the spec is fine except onerror and onload should be removed from TextTrack.
Comment 7 Philip Jägenstedt 2011-09-30 14:56:34 UTC
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.
Comment 8 Ian 'Hixie' Hickson 2011-09-30 16:15:09 UTC
That sounds more reasonable (moving the loading mechanic to just the element). I'll investigate if that'd work.
Comment 9 Ian 'Hixie' Hickson 2011-10-04 01:04:59 UTC
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.
Comment 10 Philip Jägenstedt 2011-10-04 08:19:31 UTC
Sounds good. I filed which is entangled with the loading machinery in case you want to do both at the same time.
Comment 11 Ian 'Hixie' Hickson 2011-10-15 00:11:02 UTC
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:

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.
Comment 12 contributor 2011-10-15 00:11:46 UTC
Checked in as WHATWG revision r6689.
Check-in comment: Move TextTrack.readyState to HTMLTrackElement.