[Bug 21851] revert removal of text and getCueAsHTML members; address constructor changes

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

--- Comment #33 from Glenn Adams <glenn@skynav.com> ---
(In reply to comment #32)
> (In reply to comment #27)
> > Is the main reason for your objection backwards compatibility?
> 
> My objection is
> 
> * existing scripts that use TextTrackCue will stop working without any
> indication about what's wrong

not all of them, just the ones that explicitly invoke TextTrackCue()
constructor; do you have any stats on usage in the wild?

> 
> * new scripts might be written with the assumption that the cue will get
> rendered

authors that use experimental (pre-REC) features must deal with changes; this
is not a new problem here; caveat emptor applies

> 
> > The name TextTrackCue by itself (without looking at history) doesn't imply
> > whether it gets rendered on not - in fact, not even every VTTCue is/can be
> > rendered.
> 
> Sure, but it's reasonable to assume that it can be rendered, especially
> since that's the case in current implementations.

I agree with Silvia. Furthermore, there are implementations that do not render
generic metadata mapped to generic TextTrackCue.

> 
> > The main reason I didn't introduce an UnprasedCue object is that I don't
> > really see the advantage of creating a basically empty object, just to get a
> > constructor:
> > 
> > [Constructor(double startTime, double endTime, DOMString text)]
> > interface UnparsedCue : TextTrackCue {
> > };
> 
> The advantage is that existing scripts that use the TextTrackCue constructor
> get an exception so that it's super-easy to debug why it stopped working,
> and that it is clearer for newcomers that it's a dummy cue that they have to
> parse and render themselves. (I'm open for other names if anyone can think
> of a better name.)
> 
> As for the .text property, I would suggest defining it on both UnparsedCue
> and VTTCue, and have these two interfaces inherit from TextTrackCue.

I think it better to leave on TextTrackCue as originally defined, and follow
well established O-O design principles: namely, data abstraction. By
definition, or at least by name, a TextTrackCue is associated with some "Text".
It is perfectly reasonable, and understandable to abstract this by means of a
common attribute on the base type. In fact, moving this potentially common
abstraction to concrete sub-types makes it more difficult to understand and
use.

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

Received on Monday, 12 August 2013 15:23:33 UTC