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/multipage/the-video-element.html Multipage: http://www.whatwg.org/C#sourcing-out-of-band-text-tracks Complete: http://www.whatwg.org/c#sourcing-out-of-band-text-tracks Comment: Track selection cannot be performed (synchronously) per inserted track Posted from: 2001:4c28:a032:32:99ec:df32:e805:6235 by philipj@opera.com User agent: Opera/9.80 (X11; Linux x86_64; U; Edition Next; en) Presto/2.10.289 Version/12.00
The spec text begins with "When a text track corresponding to a track element is added to a media element's list of text tracks, the user agent must set the text track mode appropriately, as determined by the following conditions:" It appears that this requires the steps that follow to be run synchronously when a track element is inserted, which is not what we want to implement. Doing so could mean that if a user has indicated a preference for English, French and Swedish (in that order) and tracks in Swedish, French and English are added by script (in that order), the Swedish and French tracks will first be enabled, and then set to hidden when the next track is added. We want to implement a heuristic that look at the set of available tracks all at once and picks enables those that that are relevant. This heuristic should be run synchronously when the parser encounters </video> (including in innerHTML) and after awaiting a stable state if a script inserts a <track> element.
As a more theoretical concern, since the spec as written asks things like "If there is a text track in the media element's list of text tracks whose text track mode is showing by default" a naive implementation of that while inserting tracks would lead to O(n^2) track insertion.
This bug was cloned to create bug 18190 as part of operation convergence.
Tough one. Thinking about it, we really want to consider the available text tracks after the in-band tracks have been considered also, which really means after the user has hit play, which seems bad, because you really want the user to be able to manipulate this UI long before they hit play... Do we just punt on in-band tracks when there are also out-of-band ones?
I punted on in-band tracks for now. Not sure what to do with those. There's some hand-wavy text there in the meantime that might work. I made this change as part of wider track changes. Let me know if the spec looks good now or not.
This aspect of the updated spec looks good to me, but I haven't reviewed all of changes so I might come back with more issues later.
Just FYI: fixed in http://html5.org/tools/web-apps-tracker?from=7325&to=7326