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#text-track-api Complete: http://www.whatwg.org/c#text-track-api Comment: Drop MutableTextTrack and make TextTrack always mutable Posted from: 24.103.99.21 User agent: Opera/9.80 (Windows NT 6.1; U; en) Presto/2.9.168 Version/11.51
Comments from the Open Video Conference, with implementors of Opera, Firefox, Chrome and Safari discussing WebVTT. There does not appear to be any good reason why MutableTextTrack exists, AFAWCT it would be simpler and more powerful to let TextTrack be mutable and have the new TrackTrack constructor create a new track. Move addCue and removeCue to TextTrack. Allowing authors to tweak the cues using scripts without copying them into a new MutableTextTrack would be more natural.
The initial idea was to not require that WebVTT parsers create data structures that are mutable, but if nobody is interested in taking that benefit into account I don't mind making all TextTracks mutable. Should I make Cues more mutable also?
(In reply to comment #2) > The initial idea was to not require that WebVTT parsers create data structures > that are mutable, but if nobody is interested in taking that benefit into > account I don't mind making all TextTracks mutable. > > Should I make Cues more mutable also? As a Web dev, I'd say "yes". But I also know that caption providers will not like it when their copyrighted content is easily change-able. OTOH, copying it to a MutableTextTrack and then making changes is not difficult, so the extra hurdle introduced by having them immutable is small. It's not like you are changing the original resource.
The only concern I'm worried about here is whether UA vendors mind them being mutable as far as I can tell having them mutable is nothing but good for content providers. I don't see a copyright issue as being relevant here.
(In reply to comment #4) > The only concern I'm worried about here is whether UA vendors mind them being > mutable � as far as I can tell having them mutable is nothing but good for > content providers. I don't see a copyright issue as being relevant here. Why would the browsers want the cues to not be mutable?
Mutable data structures are significantly more expensive and complicated.
You'll have to be more specific, because none of the people that are actually implementing this have understood which operations would be more expensive with mutable tracks.
(In reply to comment #2) > Should I make Cues more mutable also? Yes, all currently readonly IDL attributes on TextTrackCue except track should be mutable. I suggest also replacing getCueAsSource with a mutable property that causes the WebVTT cue parser to be re-run. For any modification, we could spec it to be equivalent to the current MutableTextTrack case, where the old cue is removed and a new cue is inserted.
Ok, will make things more mutable.
Checked in as WHATWG revision r6710. Check-in comment: Fold MutableTextTrack into TextTrack. http://html5.org/tools/web-apps-tracker?from=6709&to=6710
Checked in as WHATWG revision r6711. Check-in comment: Make TextTrackCue more mutable. http://html5.org/tools/web-apps-tracker?from=6710&to=6711
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: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diffs given above Rationale: Concurred with reporter's comments.