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

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

--- Comment #8 from Philip Jägenstedt <philipj@opera.com> ---
(In reply to Silvia Pfeiffer from comment #6)
> (In reply to Philip Jägenstedt from comment #5)
> > 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.
> 
> FAICT your only reason to object is that script may rely on rendering SSA by
> itself even after the browser might have already implemented an interface to
> render it. I think that's not a TextTrackCue specific problem, but one that
> applies to all new features of browsers.
> 
> If the browser exposes such cues as UnparsedCues initially, JS will
> implement the rendering. Later, the browser supports SSACues and will not
> expose UnparsedCues any longer, so JS will not kick in. So, this situation
> doesn't actually create a problem.

You're right, I didn't consider the implications of the interface changing.
That makes it possible for a script to be pedantic and check the interface
before handling a cue. A less pedantic script would still either end up with
double rendering (if both interfaces have a .text property) or rendering
"undefined" or similar (if they don't share the property name).

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

Received on Monday, 16 September 2013 09:10:18 UTC