[Bug 23113] Deal with mode for TextTrackCues that are not VTTCues

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23113

--- Comment #5 from Philip Jägenstedt <philipj@opera.com> ---
(In reply to Graham from comment #4)
> (In reply to Philip Jägenstedt from comment #3)
> > (In reply to Graham from comment #2)
> > > I think the mode='showing' approach is really a band-aid that helps but
> > > doesn't solve all the problems. So maybe the starting point here is to
> > > define some of the problems that I believe we need to solve:
> > > 
> > > Problem1: App needs to know whether the UA is already showing these captions
> > > by itself. Currently the app can set mode='showing' and not know the result
> > > in the UA.
> > > 
> > > Problem2: App needs to know whether the UA is capable of showing these
> > > captions if requested to turn them on. There is no way interrogate the UA
> > > capabilities in order to, say,allow for loading a captioning display library
> > > in advance. 
> > 
> > I don't think either of these problem will appear in current
> > implementations, since everyone who exposes VTTCue will also render it when
> > mode=='showing'. If we just avoid adding interfaces which some browsers will
> > render and some won't, then just looking at the interface will be enough.
> >
> So are you suggesting then that if the UA cannot render the inband captions
> then it should not expose them to the application? That would prevent the
> scenario where a JavaScript library handles the raw caption data when a UA
> cannot handle the format. 

Yes, that is indeed my position. We've been discussing this a lot in a big
thread on the public-html list recently. In
<http://lists.w3.org/Archives/Public/public-html/2013Sep/0004.html> I explain
why I think it's a bad idea to expose cues which can in principle be rendered
without actually implementing the rendering.

Note that this is not to say that *metadata* cues which are by design
application-specific shouldn't be exposed, they clearly should be. It's only
things like the SSA in Matroska example that I think are a bad idea.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 13 September 2013 07:07:06 UTC