Re: TextTrackCue discussions

I think an analogy might be useful to show what I'm concerned about.

Assume we were adding a way to manipulate images in JavaScript. We could
start by having an interface for binary data:

interface BinaryData {
    attribute DOMString rawData;
    attribute long size;
};

We also know that people are going to want to use bitmaps, so let's add
that:

interface BitMapImageData {
    attribute long width;
    attribute long height;

    attribute double xPixelsPerMeter;
    attribute double yPixelsPerMeter;
    attribute long colorsInColorTable;
    attribute double redChannelBitmask;
    attribute double greenChannelBitmask;
    attribute double blueChannelBitmask;

    double getPixel(long width, long height);
    setPixel(long width, long height, double data);
};

Great, now we're done. No one will ever need another image format, and
if they do, they can use BinaryData, since technically everything they'd
ever want is there.

This is basically the choice the current TextTrackCue spec gives people:
You can either have everything you'd ever want, if you know that your
cue was transmitted on the wire in WebVTT format, or you can have raw
data and you can parse it yourself, even if the browser knows how to
parse it. /Maybe/ the browser will give those attributes and functions
the same names, but I'm saying that we should require it.