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

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

--- Comment #32 from Simon Pieters <simonp@opera.com> ---
(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

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

> 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.

> 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.

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

Received on Monday, 12 August 2013 14:55:43 UTC