- 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