- From: <bugzilla@jessica.w3.org>
- Date: Sat, 23 Feb 2013 15:55:28 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21080 --- Comment #1 from Glenn Adams <glenn@skynav.com> --- an alternative approach would be to not provide a constructor, but instead have a cue creator method on a TextTrack, which has already been bound to a specific content type (and thus would allow inferring the "interpretation rules" that applies to the cue); for example, one could have: interface TextTrack { ... TextTrackCue createCue(float startTime, float endTime, DOMString text) } note that if a constructor is used and a content type is specified at construction time, then it raises the possibility of a mismatch when performing addCue() on an existing track that is associated with a different content type; for example, if one did: track = video.addTextTrack("captions","application/xml+ttml") cue = new TextTrackCue(0,1,"...","text/vtt") track.addCue(cue) should produce an exception on addCue due to content type mismatch; if instead we had: track = video.addTextTrack("captions","application/xml+ttml") cue = track.createCue(0,1,"...") track.addCue(cue) then we never have an incompatibility the present bug is a result of having a standalone constructor that does not take the track into account at construction time (in terms of its content type from which interpretation rules are to be derived) -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Saturday, 23 February 2013 15:55:30 UTC