Open mounirlamouri opened 7 years ago
@zcorpan and @fsoder have also worked a lot on this.
Would the readyState
on TextTrack
be useful for in-band tracks and script-created tracks? Is there something that's impossible with the current API, or is it a matter of convenience?
Mild overlap with #1290 here I guess? (The major difference seems to be whether you want to expose/proxy bits of the source or the source itself.)
If we add #1290, it will become convenience. However, if we want to abstract the element and the track representation, as far as I know, it's impossible to do efficiently.
FWIW, both Gecko and Blink have an internal readyState
being used for TextTrack
so I would assume finding a value for script-created and in-band tracks to be a solved issue (didn't check what they do but likely created as loaded).
Yes, 'loaded' would be the reasonable value for non-HTMLTrackElement sourced tracks. It's speced already too - https://html.spec.whatwg.org/multipage/embedded-content.html#sourcing-in-band-text-tracks step 6, https://html.spec.whatwg.org/multipage/embedded-content.html#dom-media-addtexttrack step 2.
I would be OK with this proposal or #1290, or both. We need interest to implement from more than one browser engine though.
cc @eric-carlson @bechen
I'm working on implementing the Blink media controls on top of the web exposed APIs instead of implementing our own hook and the relationship between HTMLTrackElement and TextTrack is problematic.
As far as the developers are concerned, working on
TextTrackList
is the best solution but activating aTextTrack
might fail if it is backed by aHTMLTrackElement
that fails to load. This can be observed on the element with anerror
event andreadyState
. However, even ifTextTrack
has an internal notion of ready state, it is not exposed to web pages.I would like to propose to fire the same events wrt to loading and expose the ready state via
readyState
on theTextTrack
object in addition ofHTMLTrackElement
.@foolip are you the right person to give feedback on this?