- From: <bugzilla@jessica.w3.org>
- Date: Thu, 06 Feb 2014 16:20:27 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24370 --- Comment #4 from Aaron Colwell <acolwell@google.com> --- (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. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 6 February 2014 16:20:28 UTC