This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"partial interface TextTrack { attribute DOMString kind; attribute DOMString language; readonly attribute SourceBuffer? sourceBuffer; };" TextTrack already has kind/language, and per WebIDL "All of the members that appear on each of the partial interfaces are considered to be members of the interface itself." That would mean that TextTrack now has two attributes of each kind with different definitions, which doesn't make sense. Why do scripts need to be able to modify these attributes?
This issue applies to AudioTrack/VideoTrack as well. For all of these, I'm also curious to know what the use case for the sourceBuffer attribute is. You can already get from your SourceBuffer to all the tracks, so is the reverse association really needed? I think the layering seems a little odd, I think that a TextTrack and its cues should need to know as little as possible about where they're sourced from. At least I've wanted to take Blink in that direction, so adding knowledge about SourceBuffer to TextTrack seems... not awesome.
The kind & language attributes needed to be writable because that information may not be in the init segments or media segments, but in the DASH manifest itself. Making the attributes writable allows the web application to properly annotate the kind and language in the tracks. If we can't use this syntax to overload the existing HTML5 definition, then please propose alternative syntax or help us get the attributes changed in the HTML5 spec. The sourceBuffer attribute provides an easy way for the application to find which SourceBuffer is responsible for a particular track and determine which other tracks are also sourced by that same SourceBuffer. TextTrackCue follows this same model since it has an attribute pointing to the TextTrack it is associated with for presumably the same reason. The desire for this functionality was discussed quite a while ago and you should be able to find the discussion and rational in the archive. If you still want to discuss removal of this attribute, then it should probably be in a different bug since that is unrelated to the initial issue in this bug.
(In reply to Aaron Colwell from comment #2) > The kind & language attributes needed to be writable because that > information may not be in the init segments or media segments, but in the > DASH manifest itself. Making the attributes writable allows the web > application to properly annotate the kind and language in the tracks. If we > can't use this syntax to overload the existing HTML5 definition, then please > propose alternative syntax or help us get the attributes changed in the > HTML5 spec. The way it works for out-of-band tracks is that HTMLTrackElement.kind/lang are writable, and that TextTrack is updated when those change. Is there no underlying object with MSE that could work in a similar way? If not, I suppose a HTML spec bug to make the attributes writable would be the next step.
(In reply to Philip Jägenstedt from comment #3) > (In reply to Aaron Colwell from comment #2) > > The kind & language attributes needed to be writable because that > > information may not be in the init segments or media segments, but in the > > DASH manifest itself. Making the attributes writable allows the web > > application to properly annotate the kind and language in the tracks. If we > > can't use this syntax to overload the existing HTML5 definition, then please > > propose alternative syntax or help us get the attributes changed in the > > HTML5 spec. > > The way it works for out-of-band tracks is that HTMLTrackElement.kind/lang > are writable, and that TextTrack is updated when those change. Is there no > underlying object with MSE that could work in a similar way? If not, I > suppose a HTML spec bug to make the attributes writable would be the next > step. There is no underlying object in MSE to deal with this. A long time ago there was a special method to do this, but that got removed once the SourceBuffer started exposing what tracks it was sourcing. It didn't seem to make sense to create private versions of the XXXTrack objects just to support this use case. I don't really see much harm in making these two attributes writable in all situations. It wasn't clear whether changes to these attributes would be allowed in the HTML5 timeframe so I included these "overloads" in the MSE spec so that it didn't matter when these changes made it into an HTML spec. Since MSE is an "extension spec" it seems reasonable that such "overloads" should be allowed even if it doesn't 100% match up with WebIDL. I could add a note indicating that the kind & language definitions are intended to replace the definitions in the HTML5 spec if that would clarify things.
I've filed <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24563>, let's see what Hixie thinks.
FYI, I've posted a new proposal to the public-html-media list for providing a way to specify language & kind without making these attributes mutable. http://lists.w3.org/Archives/Public/public-html-media/2014Apr/0087.html
Changes committed. https://dvcs.w3.org/hg/html-media/rev/01c9e30d71b0 Marking this bug as fixed since the overloads are gone now.