Re: A new proposal for how to deal with text track cues

On Wed, Jun 12, 2013 at 12:12 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com
> wrote:

> All of these new cue settings would end up as new attributes on the
> WebVTTCue object. This is a dangerous design path that we have taken.
>

Having a few unused attributes on an object is an effect, not a problem.  I
think your proposal adds significant complexity, without solving any real
problems.  It means adding a bunch of new restrictions to the API:
preventing developers from accessing .vertical, .size, etc., if they have
some reason to do so (they're still parsed and exposed for metadata cues);
making .kind readonly, where before it wasn't.

> Once a WebVTT file is parsed into a list of cues, the browser should
> not have to care any more that the list of cues came from a WebVTT
> file or anywhere else. It's a list of cues with a certain type of
> content that has a parsing and a rendering algorithm attached.

If it has a rendering algorithm attached, then the browser does care that
it came from a WebVTT file, since that's what that flag indicates.  I'm
also confused that you're saying you want to split the interfaces for
metadata and cues, but that if the platform supports a DVD bitmap caption
interface in the future, you'd want those to use the same interface, even
though their data and attributes would be completely different.

-- 
Glenn Maynard